OSLogger performance consideration

[toshi0383]

I noticed that OSLogger is potentially losing a built-in optimization from os.signpost.

    func log(category: String = #file, name: StaticString, _ arguments: CVarArg..., closure: () throws -> Void) throws {

https://github.com/tuist/xcodeproj/blob/master/Sources/xcodeproj/Utils/OSLogger.swift

• CVarArg... causes unwanted memory allocation of an array each time.

In WWDC 2016, Apple says "do not create a wrapper for os_log family functions". Maybe it applies to signpost too.

https://developer.apple.com/videos/play/wwdc2016/721/

Any thoughts?

[toshi0383]

closure is not escaping, therefore is inlined, so that part is okay.
Maybe adding @inline(__always) worths it, but profiling normally happens with Release builds, so it's not mandatory.

[pepicrft]

Thanks for bringing this up @toshi0383.

We can get rid of the wrapper and use the API directly from the places where we log stuff. Not sure what implications it has but if Apple suggested it, they must be doing some optimizations that we are not aware of.

[toshi0383]

My college @inamiy came up with this wrapper function. This way we don't waste memory. Maybe it worth trying it. 👌

func signpost( ..., format: StaticString, _ arg1: CVarArg, closure: () throws -> ()) throws {
    os_signpost(..., format, arg1)
    try closure()
    ...
}

func signpost( ..., format: StaticString, _ arg1: CVarArg, _ arg2: CVarArg, closure: () throws -> ()) throws {
    os_signpost(..., format, arg1, arg2)
    try closure()
    ...
}

[pepicrft]

That's a good idea @inamiy. Feel free to open a PR with the change. Otherwise, I can tackle it myself next week.
Thanks for helping to improve the library @toshi0383 🚀

[pepicrft]

@yonaskolb are you using the metrics provided by those logs? I'm considering the removal of those logs but I want to make sure you are not using them.

[yonaskolb]

Nope, not using them. Happy to have them all removed

[yonaskolb]

OSLogs removed in #453