New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-16027] Compilation speed slowed 200x on Apple Silicon in Swift 5.6 #58288
Comments
The problem is in LLVM. https://twitter.com/typesanitizer/status/1505755827814100992?s=20&t=1EJyGv_ZxaK7hpO5QMkbjw /usr/bin/time -p swiftc ~/Downloads/Accessory.swift -emit-irgen > /dev/null finishes relatively quickly. That would potentially explain why the slowdown is specific to Apple Silicon Macs. |
@swift-ci create |
Yep, generating object code for x86_64 is relatively fast. /usr/bin/time -p swiftc ~/Downloads/Accessory.swift -emit-object -target x86_64-apple-macos10.15 Finishes in about 2s. As a workaround, for macOS specifically, you could temporarily set the build settings to compile for x86_64 and run under Rosetta. That doesn't help with compiling for iOS though. |
This project is only compiled for iOS, so our work around was to rewrite this code to not use the enum (luckily it was in a demo/sample project so changing it wasn't really an issue - it's just slightly uglier now) |
This isn't a "fix" but the issue is unique to enums that have a mix of cases with/without associated values. No need to attach the whole file but just making the enum: enum Accessory: Equatable { Also brings the compile time down to the reasonable/normal length and not hang. |
Comment by Brandon (JIRA) We made a bit of a post on this here in the forums, but we're viewing this at scale in a largely modularized application. Our only current work around without impact is similar to what's in the post. Ultimately, this leaves a bit of a wack a mole game when identifying major performance hits. There was no clear warnings displaying when passing in time measurement warnings in Xcode either so it's quite difficult to track down with out full context into the codebase. Regarding the Rosetta solution, this can be valid in some cases but also introduces complications on applications that rely on build phases and external toolsets to be executed in the same environment (Rosetta or not Rosetta). It's a potential mitigation, but not a great one. We did confirm a drastic increase in performance when using Rosetta for iOS development via simulator. |
Another workaround: put the associated value in a wrapper class. I think LLVM is having trouble generating the Hashable conformance for the large struct type? |
I just checked the most recent snapshots, and this appears to be fixed on the main development snapshot as of 4/24, but is not fixed in the 5.7 snapshot from 4/25. |
Does anyone know if this is fixed in Xcode 13.3.1? |
It's not |
I'm no longer seeing the regression in Xcode 13.4 RC that was released today, so must have made it into Swift 5.7 in the past couple weeks |
It looks like Xcode 13.4 is actually Swift 5.6:
But it does appear fixed to me. I also tested the |
So it definitely seems to be fixed with Xcode 13.4, but I rebuilt the I'd love to hear from someone at Apple if this was fixed intentionally somewhere |
Yeah, nothing in the 13.4 release notes either 🤔 |
Update from Apple folks on what possibly changed would be super appreciated! |
The example above still hangs on HEAD @ 5bfef4f |
Attachment: Download
Environment
Xcode 13.3 (13E113) on MacBook Pro with M1 Max
Additional Detail from JIRA
md5: 0e1978f4b3feb8996e64b02dd75f5410
Issue Description:
Compiling the attached Accessory.swift file is 200x slower with Swift 5.6 (shipped with Xcode 13.3) vs. Swift 5.5 (shipped with Xcode 13.2.1). I spend a little time trying to get a small code sample, but didn't want to waste too much more time since it's not much code. (Twitter thread: https://twitter.com/kylebshr/status/1505752387947941888)
Co-worker with an Intel machine says it's not (noticeably) slower.
Swift 5.5:
time swiftc Accessory.swift
swiftc Accessory.swift 2.27s user 0.93s system 44% cpu 7.270 total
Swift 5.6
time swiftc Accessory.swift
swiftc Accessory.swift 483.18s user 1.27s system 99% cpu 8:05.03 total
The text was updated successfully, but these errors were encountered: