Building the stdlib faster with the debug compiler

I'm sure I'm not alone here, but I get frustrated sometimes that the debug compiler is so slow when compiling the standard library during a debug build. I looked into this a bit and found that the debug build of the swift compiler can easily be at least 20% faster with some judicious use of the always inline attribute. This isn't really surprising. So-called "zero-cost" abstractions are really expensive when optimizations are disabled. In any case, I filed a bug against clang to allow developers to run the normal inliner at -O0 to get this kind of performance improvement without massively annotating functions as being "always inline". There isn't really any downside to forcing inlining at -O0 unless you think having multiple breakpoint locations per breakpoint is bad.

If people wants to CC themselves, here is the bug:


@DaveZ I have found that using --force-optimized-typechecker makes it usable.

What's the difference in compile time for the compiler itself?

(I'm of the opinion that the -O1 work mentioned in the bug is the right longterm strategy, but I get that something maybe ought to be done short-term, and an LLVM-level flag seems reasonable for it.)

Passing -O1 to clang while building swift-frontend takes about 36% longer than -O0 on my machine. This was a unified build so the cost also includes whatever llvm/clang needs to build in order to link swift-frontend.

Personally, I don't think making -O1 "fairly debuggable" is right for everyone, especially when the fundamental problem is that people are leaning hard on the inliner optimization when they create so-called "zero-cost" abstractions.

As a followup, I just discovered SWIFT_NATIVE_SWIFT_TOOLS_PATH.

Given that I'm always building both the debug+assert and release+assert variants of a checkout, I can now build with the release+assert swift compiler by passing the path to the release+assert build binaries to the debug+assert build. This works for me. Your mileage may vary.