Yeah, the double builds are really a bit annoying.
1 Like
Since SwiftSyntax got into my SPM dependency flow, what took 1 second now seems to be taking 5.
The Emitting module for ... Phase takes 5 seconds even if I change one char in a .swift file. Effectively killing Previews
Before the SwiftSyntax, incremental builds were instantaneous on this machine. A humble M2 Ultra which feels like a Pentium 90 now.
Macros are amazing, and I can't wait for some optimization from the Xcode team.
5 Likes
For us it seems that macros adoption balloons incremental builds. 2-3-4x times - just two consequent builds can take 70+ seconds instead of 15-30 seconds before.
4 Likes
In our case we're building some xcframeworks which contain all architectures (including visionOS btw)- excluding DriverKit. 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.
This speed decrease makes the macros support currently unusable for us. Given that this is on some level just text substitution, this really should be solvable.
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. The tests work fine in the IDE. When at the command line it says:
Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
/Users/johnbushnell/Code/Kochava/Apple-KochavaSDK-Source/Apple-SwiftPackage-KochavaNetworking-Source/Sources/KochavaNetworking/Adapter.swift:494:9: external macro implementation type 'KochavaNetworkingMacrosMacros.ExecutionSynchronizeMacro' could not be found for macro 'let_execution_synchronize(executor:)'
This is running on the latest command line tools:
Xcode 15.2
Build version 15C500b
2 Likes
Remove the -sdk parameter from your Xcodebuild command. It forces the macros to be built for the target instead of the host.
while i donāt disagree that this is a huge problem (that i am personally incredibly frustrated with), itās not quite as simple as text substitution. running a macro requires compiling SwiftSyntax, and SwiftSyntax is just a huge, bloated gyb library that takes an extremely long time to compile, especially in release mode. i donāt see many viable solutions that donāt involve distributing SwiftSyntax as a binary dependency, which is not something that is well-supported in the SPM ecosystem.
2 Likes
@taylorswift Well, I didn't say solving it would necessarily be easy. I'm also not sure my problem is entirely the macros. When in the IDE I do a clean build the framework for a single architecture (iOS) the times I get are:
Without macros: 9 seconds
With macros: 29 seconds
These are on an M1 Max, btw.
Multiplying that out to 10 architectures, that's a floor value of 90 seconds (3 minutes) without macros and 290 seconds (4.9 minutes) with macros. So when the xcframework creation process balloons up to around 5 minutes without the macros, I wonder a little about where the additional time is coming in, but it doesn't seem too controversial.
In the case with macros, there theoretically only needs to be 20 additional seconds per architecture (2*10=200s, or 3.33m). But we're seeing around an additional +27m.
It seems like the ballooning of 3.33m to 27m may be due to something happening with the macros during the archive process that wasn't intended- beyond the basic clean compilation of the swift syntax support for release. Or do you know why there would be such a difference?
1 Like
I'm curious as to why there isn't a binary distribution for SwiftSyntax?
6 Likes
1.5 minutes.
for binary dependencies in general, it is a combination of poor SPM support and the issue of āwhere are we going to store these binaries?ā
for swift syntax specifically, it would make a lot of sense to host its binaries on swift.org alongside the toolchain.
7 Likes
In my team we also decided against using macros as itās too expensive build time wise. From local developer iteration time to CI builds. Itās quite unfortunate. I hope there will be a distributed binary eventually or some other solution. Someone already made a proof of concept for a distributed binary here:
But SwiftSyntax is by Apple so I think Apple should ship and maintain some binary.
1 Like
Just yesterday I installed the same rule for my personal development.
Same story as everyone else, in a nutshell - I saw some nice-looking package (swift-foundation-extensions, in this instance), added it to my project, and then saw my builds suddenly taking way longer. Then noticed the dreaded "SwiftSyntax" named in the build logs.
What was a clean build time of about fifteen seconds became several minutes. 
("how often do you do clean builds, though, really?" - ugh, a lot. I'm using Xcode and it's got some bugs regarding detecting changed sources, not to mention its infamous bugginess regarding stale compiler errors)
6 Likes
i will note that a clean build is currently required in VSCode every time a source file is moved, renamed, or deleted, because indexstore cannot replace the references to the old source locations. (this is also often accompanied by a sourcekit-lsp crash, but that is a separate issue.)
2 Likes
This is how long it adds to a build on Xcode Cloud: 12 minutes
9 Likes
@Ignacio_Soto that's horrifying. I don't think it makes sense for a core language feature to take longer to compile than the actual project itself.
7 Likes
I filed FB13561794 about Xcode's double builds of swift-syntax (which doesn't happen when building with SPM), so maybe Xcode 15.3 will make progress.
Speaking of Xcode 15.3, I'm currently tracking a 100% build performance regression for my small project (FB13561825). Seems smaller file builds are taking much longer.
1 Like
@Jon_Shier experience a regression (not 100% for me, closer to 30%) as well, can confirm it is slower for sure. Iāll dupe your radars.
based on this thread: Support binary dependencies on Linux (and Windows?) - #6 by Braden_Scothern it sounds to me that binary dependencies are not on the roadmap for swift on linux (or Windows, for that matter.)
i am having trouble brainstorming possible solutions that donāt involve some kind of binary distribution for SwiftSyntax on linux. curious if anyone else has any ideas here.
1 Like
I pitched this in a similar thread Macro Adoption Concerns around SwiftSyntax - #76 by anreitersimon
Basically i would propose to bundle it with the toolchain.
That would avoid having to host binaries externally.
4 Likes
Would love to see the core team pitch in on this thread as a lot of us are wondering whether itās a good idea to adopt macros right now, and this IMO is a significant issue that factors into the decision making process.
9 Likes