Hi, all. I filed SR-292 <https://bugs.swift.org/browse/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.
Opinions?
Jordan
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
