StdlibUnittest and Debug compilers

(Jordan Rose) #1

Hi, all. I filed SR-292 <> today complaining about StdlibUnittest taking 13 minutes to build on my machine, 9 of which are spent in SIL optimization. I had a pretty strong feeling that this happened some time in the last few months.

Continuing to experiment, however, I found that this only occurred when I was compiling the Swift compiler in Debug mode. Now, debug builds are super important for those working on the compiler, because you can't interactively debug a Release build in any meaningful way. But at the same time, it's not really a configuration that we want to be optimizing for.

Running under Instruments showed me that unoptimized DenseMaps are not fast, but other than that it's mostly just that we do a lot of SIL work on a lot of code.

I've thought of a few possible "solutions" to let me keep my Debug build:

(1) Compile StdlibUnittest as -Onone in Debug mode. This means I'm not really testing a lot of things since they depend on the optimizer having actually inlined the code, but it's already not a shipping configuration anyway, and we do have buildbots.

(2) Break out the expensive parts of StdlibUnittest into Yet Another Private Library, and then disable that library in Debug compiler builds.

(3) Always keep two active build directories, a Debug compiler and a Release compiler, and come up with an aggregate target that doesn't build StdlibUnittest. That way I can still run individual tests with my Debug compiler, but I'd only ever run the whole test suite with the Release one.