Potential optimizations about zld

[michaeleisel]

Yes, binary size increase is a downside. But the CPU cost of a larger binary size (e.g., due to more page faults) may generally compensated for by the linker being faster. I think we can let consumers test that for themselves.

Besides size, it seems like Objective-C and C++ exceptions use compact unwind info, but Swift does not. Also, if an Objective-C method throws and unwinds into a Swift context, Swift still doesn't need compact unwind info. So for a pure Swift project like @kastiglione is working with, it indeed seems fine. Then there's that article, which discusses backtrace being unsuitable for crash reporting, and so needing compact unwind info. But since this is a debug build, that's not as much of a concern anyways

[michaeleisel]

Closing, will resume discussion in #7

[michaeleisel]

-no_deduplicate is a good one. For Xcode, the default is to add -no_deduplicate for Debug but to deduplicate for Release.

-no_compact_unwind seems a little more interesting. I'm not sure it's really language-specific, I believe it's helping at the assembly level to backtrace, a la https://www.mikeash.com/pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html . I'd like to understand the exact situations in which it can be a drawback to use flag (although it definitely seems good for debug in general)

[bjorn3]

I'd like to understand the exact situations in which it can be a drawback to use flag

It increases the size of the binary.