Recently we had some issues with getting readable stack traces on crash logs when using app center. We did not have the function that produced a crash (with a fatalError() inside) in the actual stack trace. We tried several different approaches and the only change in the project that resulted in more readable crash logs was to change the Swift Compiler - Code Generation , optimization level from -O to -Osize. That change solves the crash logs and gives us a bit more readable stack traces but are we paying a huge cost for doing that?
My question is, how much of a performance impact would we expect if we do not use the recommended -O optimization level and use -Osize instead. I've read the swift blog post where this option was introduced in Swift 4.1 but I am still unaware of the consequences performance wise. Our code base is entirely in Swift and we have several in-house dependencies that are dynamic frameworks which are also in Swift.
It should be fine. -Osize still runs most of the optimizations that -O does (in particular, it runs all of the passes that prevent the worst performance hazards of -Onone). The main easily observable difference is that the inliner is less aggressive, which will occasionally prevent the compiler from finding further optimization opportunities, but is usually pretty innocuous.
You may notice that I'm being a little bit hand-wavy about all of this; that's because the exact impact depends quite a bit on what exactly you're doing. But for "normal" apps, my rough expectation is that -Osize will have little to no performance impact (it actually improves performance sometimes). As always, the best advice is to measure the performance before and after, and report bugs for any cases where there are large regressions.
Granted I’m super rusty w.r.t. how DWARF et al work, but if the cause is merely inlining, shouldn’t the symbol at the inlined address still resolve to the name of the original, now-inlined function?