Yeah, tried that, the emit module phase increased to about 115s.
Actually, Emit Swift module is about the same (at the high end of the 80 - 100s range I've seen) but overall build time increased about 20s.
1 Like
Further investigation seems to show this is actually a macro performance problem. The emit module step seems to wait until all of the macros in the project are expanded before actually starting its work, which then takes about 25s to complete, rather than 100s that's indicated in the build log. This is exacerbated by two long standing macro performance issues: a debug swift-syntax build and treating every macro invocation as a separate process launch. This is extremely slow, as it hugely overcommits the system's cores with these separate processes, especially on systems with security software that tries to inspect every file read and process launch. Command line builds which limit the build system's parallelism and leave cores for the macros and security software actually complete faster than Xcode's default.
Has there been any progress in reducing the impact of macros on build time?
11 Likes
I tried turning off testability for the debug builds and found it had no effect on the emit module phase
I tried that too, as well removing any debugging ability for the app target and saw no improvement on build times.
Further investigation seems to show this is actually a macro performance problem.
Looking at Activity Monitor, I can see macro processes running for roughly the same time as the Emit Swift Module runs. Would be great if the expansion only ran when changing macro implementations or members/sources they're attached to, since currently they're ran on every change, as small as adding a print statement to an unrelated piece of code.
Yes, we see the same thing. Even for a minor change in a file with no macros, the emit module phase is running for about 25s (all of this testing has been on an M2 Max) with macro processes active during that time.
I am starting to investigate build performance issues around macros which seems to be our biggest at the moment. It's not clear this is the same problem? But either way, build performance is definitely on my radar.
4 Likes
While investigating a regression in our test runtime performance, we found that the thread sanitizer was having a huge impact and so disabled it. Shockingly, this also fixed our build time regression, including the huge emit modules phase. Overall build time decreased from 318s to 162s simply by disabling the thread sanitizer. I don't know if this was a regression in Xcode 16 or an interaction between the thread sanitizer and our security software running during the build, but in both build and test runtime cases, disabling the sanitizer fixed most of our regression.
4 Likes
@tshortli Coming back to this, it looks like the Emit Modules phase isn't reusing macro expansions during incremental builds, as seen in this thread. While we hope for macros to be optimized, is there any hope for more sharing of build artifacts for the emit step?