Skip to content
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

Open
kylebshr opened this issue Mar 21, 2022 · 17 comments
Open

[SR-16027] Compilation speed slowed 200x on Apple Silicon in Swift 5.6 #58288

kylebshr opened this issue Mar 21, 2022 · 17 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. performance

Comments

@kylebshr
Copy link

Previous ID SR-16027
Radar rdar://problem/90549915
Original Reporter @kylebshr
Type Bug

Attachment: Download

Environment

Xcode 13.3 (13E113) on MacBook Pro with M1 Max

Additional Detail from JIRA
Votes 7
Component/s
Labels Bug
Assignee None
Priority Medium

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

@typesanitizer
Copy link

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.

@typesanitizer
Copy link

@swift-ci create

@typesanitizer
Copy link

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.

@kylebshr
Copy link
Author

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)

@thedavidharris
Copy link

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 {
case none(Bool)
case drill(Bool)
case radio(MarketRadio.Style)
case checkbox(MarketRadio.Style)
case toggle(MarketRadio.Style)
case button(MarketRadio.Style)
case noTap(Bool)
}

Also brings the compile time down to the reasonable/normal length and not hang.

@swift-ci
Copy link
Collaborator

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.

@saagarjha
Copy link
Contributor

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?

@keith
Copy link
Collaborator

keith commented Apr 26, 2022

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.

@keith
Copy link
Collaborator

keith commented Apr 27, 2022

Here's a symbolicated trace from a local 5.7 RelWithDebugInfo build:

image

@StarLard
Copy link

Does anyone know if this is fixed in Xcode 13.3.1?

@keith
Copy link
Collaborator

keith commented Apr 27, 2022

It's not

@sethfri
Copy link

sethfri commented May 12, 2022

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

@keith
Copy link
Collaborator

keith commented May 13, 2022

It looks like Xcode 13.4 is actually Swift 5.6:

% DEVELOPER_DIR=/Applications/Xcode-13.4.0-RC1.app swift -version
swift-driver version: 1.45.2 Apple Swift version 5.6.1 (swiftlang-5.6.0.323.66 clang-1316.0.20.12)
Target: arm64-apple-macosx12.0

But it does appear fixed to me. I also tested the release/5.7 branches which still do not appear to be fixed. I wonder if a fix landed on the release/5.6 branch since the last Xcode release? Maybe someone from Apple would know

@keith
Copy link
Collaborator

keith commented May 16, 2022

So it definitely seems to be fixed with Xcode 13.4, but I rebuilt the release/5.6 branch and it is not fixed there 🤔

I'd love to hear from someone at Apple if this was fixed intentionally somewhere

@kylebshr
Copy link
Author

Yeah, nothing in the 13.4 release notes either 🤔

@luispadron
Copy link

Update from Apple folks on what possibly changed would be super appreciated!

@keith
Copy link
Collaborator

keith commented Aug 17, 2022

The example above still hangs on HEAD @ 5bfef4f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. performance
Projects
None yet
Development

No branches or pull requests

10 participants