{"id":42256,"date":"2024-02-27T14:35:48","date_gmt":"2024-02-27T19:35:48","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=42256"},"modified":"2024-03-11T15:28:21","modified_gmt":"2024-03-11T19:28:21","slug":"slow-swift-macro-compilation","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/02\/27\/slow-swift-macro-compilation\/","title":{"rendered":"Slow Swift Macro Compilation"},"content":{"rendered":"

Vatsal Manot<\/a>:<\/p>\n

\n

Folks, if you’re also frustrated with the state of Swift Macros (w.r.t. compile times), please engage on the forums thread here.<\/p>\n

I can’t think of any other language where such a fundamental feature is dependent on a heavy source package that needs to be recompiled every clean build.<\/p>\n<\/blockquote>\n\n

John Bushnell<\/a>:<\/p>\n

Prior to adding macros one xcframework takes 257.7 seconds (4.3 minutes) to build. After adding macros it takes 2004.5 seconds (33.4 minutes). This is a 7.76x increase. This is with one macro implemented in one location in code, so it’s not related to how many times the macro is used.<\/p>

This speed decrease makes the macros support currently unusable for us.<\/p>\n

[…]<\/p>

There’s also a secondary issue, which because of the speed issue I don’t really need to take it further at this point, but it’s that tests do not support these macros for some reason when run from the command line.<\/p><\/blockquote>\n\n

Wade Tregaskis<\/a>:<\/p>\n

Same story as everyone else, in a nutshell - I saw some nice-looking package (swift-foundation-extensions<\/a>, in this instance), added it to my project, and then saw my builds suddenly taking way<\/em> longer. Then noticed the dreaded “SwiftSyntax” named in the build logs.<\/p>

What was a clean build time of about fifteen seconds became several minutes.<\/p>

(“how often do you do clean builds, though, really?” - ugh, a lot<\/em>. I’m using Xcode and it’s got some bugs regarding detecting changed sources, not to mention its infamous bugginess regarding stale compiler errors)<\/p><\/blockquote>\n\n

John McCall<\/a>:<\/p>\n

\n

The LSG is aware that there are build-system issues causing a lot of pain for macro adopters and their downstreams. From an abstract language perspective, I don’t think any of those problems are particularly challenging to the point of requiring an overall design change to macros; the project just needs to put in the work to fix them. I can’t tell you when that will happen, though, which I know is not a satisfying answer.<\/p>\n<\/blockquote>\n\n

Vatsal Manot<\/a>:<\/p>\n

Be aware of the fact that you’re adding ~38,000 LoC of Swift source code to your project. This cost is forwarded to anyone consuming your Swift packages.<\/p>

Be aware of the fact that SPM currently fetches the entire git history of the SwiftSyntax repo<\/a>. This is a separate but, in my view, not unrelated issue as it directly factors into the cost of adopting macros.<\/p>

Just adding SwiftSyntax can potentially add up to 12 minutes<\/strong><\/a> to your build time on Xcode Cloud as noted by @Ignacio_Soto<\/a>.<\/p>

It’s peculiar enough that a core language feature is tied to a still-maturing package manager riddled with performance\/build-systems issues, but what I find extremely disappointing is that these issues aren’t mentioned anywhere<\/strong> in any official documentation\/release notes.<\/p><\/blockquote>\n\n

Previously:<\/p>\n