programing

Swift 컴파일 시간이 왜 이렇게 느리죠?

oldcodes 2023. 4. 9. 22:22
반응형

Swift 컴파일 시간이 왜 이렇게 느리죠?

Xcode 6 베타 6을 사용하고 있습니다.

이것은 얼마 전부터 신경이 쓰였지만, 지금은 거의 사용할 수 없는 지경에 이르렀다.

제 프로젝트에는 65개의 Swift 파일과 몇 개의 브리지된 Objective-C 파일이 포함되어 있습니다(이것은 문제의 원인이 아닙니다).

Swift 파일을 약간 수정하면(앱에서 거의 사용되지 않는 클래스에 빈 공간을 추가하는 등) 지정된 대상의 Swift 파일 전체가 다시 컴파일됩니다.

100%인 것으로 CompileSwift가 Xcode를 하는 swiftc재빠르다

좀 더 조사를 해봤는데 앱 위임자를 기본 컨트롤러로만 유지하면 컴파일은 매우 빠릅니다만, 프로젝트 파일을 추가할수록 컴파일 시간이 점점 느려지고 있었습니다.

현재 65개의 소스 파일만 있으면 1회 컴파일하는 데 약 8/10초가 소요됩니다.전혀 빠르지 않아요.

문제 외에는 이 문제에 대해 언급한 게시물을 본 적이 없지만, Xcode 6의 이전 버전입니다.그래서 저만 그런 건지 궁금해요.

갱신하다

Alarmofire, Oiler, CryptoSwift와 같은 GitHub에서 Swift 프로젝트를 몇 가지 확인했지만 실제로 비교할 만한 Swift 파일은 없었습니다.가 발견한 프로젝트는 괜찮은 사이즈로 시작한 것 뿐이었다. Swift 였다.HN은 소스 파일이 수십 개밖에 없지만 동일한 것을 확인할 수 있었습니다. 하나의 단순한 공간으로 프로젝트 전체를 재컴파일해야 했기 때문에 약간의 시간(2/3초)이 소요).

분석과 컴파일이 모두 빠르게 진행되는 Objective-C 코드에 비하면 Swift는 결코 큰 프로젝트를 처리할 수 없을 것 같은 느낌이 듭니다만, 틀렸다고 말해 주세요.

Xcode 6 베타 7로 업데이트

여전히 전혀 나아지지 않았다.말도 안 되는 일이 벌어지기 시작했어이 부족하기 때문에#import스위프트에서는 애플이 이것을 어떻게 최적화할 수 있을지 정말 모르겠다.

Xcode 6.3 및 Swift 1.2로 업데이트

Apple은 증분 빌드(및 다른 많은 컴파일러 최적화)를 추가했습니다.이러한 이점을 보려면 코드를 Swift 1.2로 마이그레이션해야 하는데, Apple은 이를 위해 Xcode 6.3에 도구를 추가했습니다.

여기에 이미지 설명을 입력하십시오.

하지만

나처럼 너무 빨리 기뻐하지 마.빌드를 증분화하기 위해 사용하는 그래프 솔버는 아직 최적화되지 않았습니다.

실제로 첫 번째로 함수 시그니처의 변경을 조사하지 않기 때문에 한 메서드의 블록에 공간을 추가하면 해당 클래스에 따라 모든 파일이 재컴파일됩니다.

둘째, 변경에 영향을 받지 않더라도 재컴파일된 파일을 기반으로 트리를 만드는 것 같습니다.예를 들어 이 세 가지 클래스를 다른 파일로 이동한 경우

class FileA: NSObject {
    var foo:String?
}
class FileB: NSObject {
    var bar:FileA?
}
class FileC: NSObject {
    var baz:FileB?
}

「」를 는,FileA 「마크가 붙어 있다」라고 FileA시시시컴컴컴다다다은 또한 재컴파일 할 이다.FileB은 (의 입니다).FileA), ,FileCFileB컴파일이 되어 버립니다.왜냐하면, 그것은 것입니다.이치노FileC「」는하지 않는다.FileA

그래서 나는 그들이 그 의존성 나무 해결사를 개선하기를 바란다...이 샘플 코드로 레이더를 열었습니다.

Xcode 7 베타 5 및 Swift 2.0으로 업데이트

어제 Apple이 베타 5를 출시했는데, 출시 노트 안에 다음과 같은 내용이 있습니다.

Swift Language & Compiler • 증분 빌드: 함수 본문만 변경해도 종속 파일이 재구축되지 않습니다(153529)

나는 그것을 시도해 보았고 이제는 정말 잘 작동하고 있다고 말해야 한다.이들은 증분 빌드를 신속하게 크게 최적화했습니다.

보세요.swift2.0XCode 7은 5로 되어 있습니다.컴파일러의 기능 향상에 만족하실 것입니다(단, XCode 7의 글로벌 상태는 아직 느리고 버그가 있습니다).

Xcode 8.2를 사용한 업데이트

이 문제에 대한 마지막 업데이트는 오랜만이므로, 여기 있습니다.

저희 앱은 거의 독점적인 Swift 코드의 약 20,000 행으로, 품위있지만 뛰어나지는 않습니다.그것은 빠른 2와 빠른 3이동을 거쳤다.2014년 중반의 Macbook Pro(2.5GHz Intel Core i7)로 컴파일은 5/6m 정도 소요되며, 깔끔한 빌드에서는 문제가 없습니다.

그러나 애플이 다음과 같이 주장했음에도 불구하고 증분 구축은 여전히 우스갯소리입니다.

작은 변경만 있을 경우 Xcode는 전체 대상을 재구축하지 않습니다.(28892475)

분명히 많은 사람들이 이 말도 안 되는 말을 듣고 웃었다고 생각합니다(프로젝트 파일에 개인(프라이빗) 자산 하나를 추가하면 모든 것이 재컴파일됩니다).

애플 개발자 포럼에서 이 스레드를 지적하고 싶습니다.이 포럼에서는 이 문제에 대한 더 많은 정보를 얻을 수 있습니다(또한 Apple의 개발 커뮤니케이션을 가끔 고맙게 생각합니다).

기본적으로 사람들은 증분 빌드를 개선하기 위해 몇 가지 방법을 생각해냈습니다.

  1. HEADER_MAP_USES_VFS이 ""로 됨"true
  2. 「」를 무효로 .Find implicit dependencies의 계획으로
  3. 새 프로젝트를 생성하고 파일 계층을 새 프로젝트로 이동합니다.

솔루션 3을 사용해 보겠습니다만, 솔루션 1/2은 효과가 없었습니다.

이 모든 상황에서 아이러니하게도 이 문제에 대한 첫 번째 게시물을 보면 첫 번째 컴파일 슬러지에 이르렀을 때 우리는 빠른 1 또는 빠른 1.1 코드와 함께 Xcode 6을 사용했고, 2년 정도 지난 지금 애플의 실제 개선에도 불구하고 상황은 Xcode 6과 마찬가지로 심각하다는 것입니다.아이러니하다.

사실 매일매일의 좌절감 때문에 Obj/C 대신 Swift를 선택한 것을 정말 후회하고 있습니다.(App Code로 전환하기도 하지만 그건 다른 이야기)

아무튼 이 SO 게시글은 32k+ 조회수와 143 업을 기록하고 있어서 저만 그런 게 아닌 것 같아요.여러분, 이 상황을 비관하더라도 조금만 참으세요. 터널 끝에 빛이 있을지도 몰라요.

시간(그리고 용기)이 있다면!나는 애플이 이것에 대한 레이더를 환영한다고 생각한다.

Xcode 9를 사용한 갱신

오늘 우연히 만나보세요.Xcode는 현재의 끔찍한 성능을 개선하기 위해 조용히 새로운 빌드 시스템을 도입했습니다.워크스페이스 설정을 통해 활성화해야 합니다.

여기에 이미지 설명 입력

아직 시도했지만 완료 후 이 게시물을 업데이트합니다.유망해 보이긴 하지만.

롭 네이피어가 옳았어요컴파일러가 berzek 상태가 된 것은 1개의 파일(실제로는 1개의 메서드)입니다.

이제, 날 오해하지마.Swift는 매번 모든 파일을 재컴파일하지만, 지금 좋은 점은 Apple이 컴파일한 파일에 대해 실시간 컴파일 피드백을 추가했다는 것입니다.그러면 Xcode 6 GM은 이 스크린샷에서 볼 수 있듯이 어떤 Swift 파일이 컴파일되고 있는지와 컴파일 상태를 실시간으로 보여줍니다.

여기에 이미지 설명을 입력하십시오.

따라서 어떤 파일이 이렇게 오래 걸리는지 알면 매우 편리합니다.내 경우엔 이런 코드 조각이었어

var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
        "url" : self.url?.absoluteString ?? "",
        "title" : self.title ?? ""
        ])

return dic.copy() as NSDictionary

속성 " " " " " the because because because " 。titlevar title:String? andNSString컴파일러가 이 컴파일러를 에 추가할 때 미쳐버렸습니다.NSMutableDictionary.

변경처:

var dic = super.json().mutableCopy() as NSMutableDictionary
dic.addEntriesFromDictionary([
        "url" : self.url?.absoluteString ?? "",
        "title" : NSString(string: self.title ?? "")
        ])

return dic.copy() as NSDictionary

컴파일을 10/15초(아마도 그 이상)에서 1초로 줄였습니다.신기하네요.

Swift 코드 약 10만 줄과 ObjC 코드 약 30만 줄이 있기 때문에 이에 대처하기 위해 여러 가지 시도를 했습니다.

첫 번째 단계는 함수 컴파일 시간 출력에 따라 모든 함수를 최적화하는 것이었습니다(예: https://thatthinginswift.com/debug-long-compile-times-swift/)).

다음으로 모든 swift 파일을 하나의 파일로 병합하는 스크립트를 작성했습니다.이로 인해 접근레벨이 깨졌지만 컴파일 시간이 5~6분에서~1분으로 단축되었습니다.

Apple에 문의한 결과, 이하를 실시하도록 어드바이스 하고 있기 때문에, 이 기능은 폐지되었습니다.

  1. 컴파일러 - 빌드 설정에서 ' 모듈 를 켜십시오Swift 컴파일러 - 코드 생성' 빌드 설정에서 '전체 모듈 최적화'를 켜십시오. 선택합니다.'Fast, Whole Module Optimization'

여기에 이미지 설명 입력

  1. Compiler - Flags'에서 빌드를 'Swift Compiler - Custom Flags'를 합니다.'-Onone'

여기에 이미지 설명 입력 여기에 이미지 설명 입력

이러한 플래그가 설정되면 컴파일러는 모든 Swift 파일을 한 번에 컴파일합니다.Marge 스크립트를 사용하면 파일을 개별적으로 컴파일하는 것보다 훨씬 빠릅니다.만'이 '만'이 없어요.-Onone'오버라이드하면 모듈 전체도 최적화되며 속도가 느려집니다.할 때'-Onone'다른 Swift 플래그의 플래그는 최적화를 중지하지만 모든 Swift 파일을 한 번에 컴파일하는 것을 중지하지는 않습니다.

모듈 전체의 최적화에 대한 자세한 내용은 Apple의 블로그 투고를 참조하십시오.https://swift.org/blog/whole-module-optimizations/

이러한 설정으로 Swift 코드가 30초 이내에 컴파일 될 수 있습니다.-) 다른 프로젝트에서 어떻게 동작하는지는 알 수 없지만 Swift 컴파일 시간이 여전히 문제라면 시도해 보는 것이 좋습니다.

빌드에 는, 「앱 스토어 빌드」를 .'-Onone'최적화가 실가동 빌드에 권장되므로 플래그가 표시됩니다.

프로젝트의 규모와는 거의 관계가 없습니다.아마 특정 코드 조각일 거예요 한 줄이라도요프로젝트 전체가 아니라 한 번에 한 파일씩 컴파일하여 테스트할 수 있습니다.또는 빌드 로그를 보고 어떤 파일이 이렇게 오래 걸리는지 확인해 보십시오.

문제를 일으킬 수 있는 코드의 일례로서 이 38행의 gig는 베타7에서 컴파일 하는데 1분 이상 걸립니다.이 모든 것은 다음 1개의 블록에 의해 발생합니다.

let pipeResult =
seq |> filter~~ { $0 % 2 == 0 }
  |> sorted~~ { $1 < $0 }
  |> map~~ { $0.description }
  |> joinedWithCommas

한두 줄이면 컴파일할 수 있습니다.이 문제는 컴파일러의 기하급수적인 성장(아마도 요인 성장)을 일으키고 있다는 것입니다.이상적이지 않은 것은 분명합니다.또, 그러한 상황을 특정할 수 있는 경우는, 레이더를 열어 이러한 문제를 해결할 필요가 있습니다.

컴파일 시간을 늦추는 특정 파일을 식별하려면 xctool을 통해 명령줄에서 컴파일 시간을 파일 단위로 얻을 수 있습니다.

주의할 점은 디폴트로는 각 CPU 코어당2개의 파일이 동시에 구축되며 "net" 경과시간이 아닌 절대 "user" 시간이 표시됩니다.이렇게 하면 병렬화된 파일 간에 모든 타이밍이 균등하게 나타나며 매우 비슷해 보입니다.

이 문제를 해결하려면 파일 빌드가 병렬화되지 않도록 플래그를 1로 설정하십시오.시간이 더 걸리겠지만, 결국 파일별로 비교할 수 있는 "net" 컴파일 시간이 생기게 됩니다.

다음 예시는 이 기능을 수행하는 명령어입니다.

xctool -workspace <your_workspace> -scheme <your_scheme> -jobs 1 build

"Compile Swift files" 단계의 출력은 다음과 같습니다.

...
   ✓ Compile EntityObserver.swift (1623 ms)
   ✓ Compile Session.swift (1526 ms)
   ✓ Compile SearchComposer.swift (1556 ms)
...

이 출력에서 컴파일하는 데 다른 파일보다 시간이 오래 걸리는 파일을 빠르게 식별할 수 있습니다.또한 리팩터링(명시적 캐스트, 유형 힌트 등)이 특정 파일의 컴파일 시간을 단축하고 있는지 여부를 정확하게 판단할 수 있습니다.

주의: 기술적으로 다음과 같은 방법으로도 할 수 있습니다.xcodebuild하지만 출력은 믿을 수 없을 정도로 장황하고 소비하기 어렵습니다.

내 경우 Xcode 7은 전혀 차이가 없었다.컴파일하는 데 몇 초가 걸리는 여러 함수가 있었습니다.

// Build time: 5238.3ms
return CGSize(width: size.width + (rightView?.bounds.width ?? 0) + (leftView?.bounds.width ?? 0) + 22, height: bounds.height)

옵션 포장을 해제한 후 빌드 시간이 99.4% 감소했습니다.

// Build time: 32.4ms
var padding: CGFloat = 22
if let rightView = rightView {
    padding += rightView.bounds.width
}

if let leftView = leftView {
    padding += leftView.bounds.width
}
return CGSizeMake(size.width + padding, bounds.height)

투고 및 투고에서 더 많은 예를 참조하십시오.

Xcode용 빌드 시간 분석기

Xcode 플러그인을 개발했습니다.이 플러그인은, 이러한 문제를 겪고 있는 사람에게 편리합니다.

이미지

Swift 3에서 개선 사항이 있을 것으로 보이므로 Swift 코드가 더 빨리 컴파일될 수 있기를 바랍니다.

스위프트 컴파일러는 고칠 수 없겠지만 고칠 수 있는 건 우리 코드야!

Swift ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★」-Xfrontend -debug-time-function-bodies코드의 보틀 넥을 찾아 컴파일 시간을 대폭 단축할 수 있습니다.

터미널에서 다음을 실행하고 결과를 분석합니다.

xcodebuild -workspace App.xcworkspace -scheme App clean build OTHER_SWIFT_FLAGS="-Xfrontend -debug-time-function-bodies" | grep [1-9].[0-9]ms | sort -nr > culprits.txt

멋진 브라이언 이라스는 스위프트 편집 시간에 대한 훌륭한 기사를 썼다.

해결책은 캐스팅입니다.

저는 이렇게 많은 사전을 가지고 있었습니다.

["title" : "someTitle", "textFile" : "someTextFile"],
["title" : "someTitle", "textFile" : "someTextFile"],
["title" : "someTitle", "textFile" : "someTextFile"],
["title" : "someTitle", "textFile" : "someTextFile"],
.....

컴파일하는 데 약 40분이 걸렸습니다.내가 사전을 이렇게 주조하기 전까지는:

["title" : "someTitle", "textFile" : "someTextFile"] as [String : String],
["title" : "someTitle", "textFile" : "someTextFile"] as [String : String],
["title" : "someTitle", "textFile" : "someTextFile"] as [String : String],
....

이것은, 애플리케이션에 하드 코드화한 데이터 타입에 관한 다른 거의 모든 문제에 유효했습니다.

주의할 점은 Swift 타입 추론 엔진은 네스트 타입에서는 매우 느릴 수 있다는 것입니다.시간이 오래 걸리는 개별 컴파일 유닛의 빌드로그를 보고 Xcode-spawn 명령어 전체를 복사하여 터미널 창에 붙여넣은 후 CTRL-\ 키를 눌러 진단하면 속도 저하의 원인을 대략 알 수 있습니다.완전한 예에 대해서는, http://blog.impathic.com/post/99647568844/debugging-slow-swift-compile-times 를 참조해 주세요.

또한 디버깅용으로 컴파일할 때(Swift 또는 Objective-C 중 하나)가 [Build Active Architecture Only]으로 설정되어 있는지 확인합니다.

여기에 이미지 설명 입력

이 모든 것이 베타판이고 Swift 컴파일러가 열려 있지 않기 때문에 당신의 질문에 대한 진정한 답은 없는 것 같습니다.

우선 Objective-C를 Swift 컴파일러에 비교하는 것은 다소 잔인하다.Swift는 아직 베타판이고, 애플은 번개 같은 속도를 제공하는 것 이상의 기능 제공과 버그 수정 작업을 하고 있다고 확신합니다(가구를 사는 것으로 집을 짓기 시작하는 것은 아닙니다).나는 애플이 조만간 컴파일러를 최적화할 것이라고 생각한다.

어떤 이유로든 모든 소스 파일을 완전히 컴파일해야 하는 경우 별도의 모듈/라이브러리를 작성하는 옵션이 있을 수 있습니다.그러나 Swift는 언어가 안정될 때까지 라이브러리를 허용할 수 없기 때문에 이 옵션은 아직 가능하지 않습니다.

컴파일러를 최적화할 수 있을 것 같습니다.미리 컴파일된 모듈을 만들 수 없는 것과 같은 이유로 컴파일러가 모든 것을 처음부터 컴파일해야 할 수도 있습니다.그러나 언어가 안정된 버전에 도달하고 바이너리의 포맷이 더 이상 변경되지 않으면 라이브러리를 만들 수 있습니다.또한 컴파일러도 작업을 최적화할 수 있습니다.

애플만이 알 수 있는 추측이지만...

Xcode 8의 경우 프로젝트 설정으로 이동하여 Editor > Add Build Setting > Add User-Defined Setting 순으로 선택하고 다음을 추가합니다.

SWIFT_WHOLE_MODULE_OPTIMIZATION = YES

이 플래그를 추가하면 40KLOC의 신속한 프로젝트를 위해 클린 빌드 컴파일 시간이 7분에서 65초로 기적적으로 단축되었습니다.또, 2명의 친구가, 기업 프로젝트에서도 같은 향상을 경험하고 있는 것을 확인할 수 있습니다.

Xcode 8.0의 버그일 것으로 생각됩니다.

편집: 일부 사용자에게는 Xcode 8.3에서 더 이상 작동하지 않는 사람도 있습니다.

안타깝게도 Swift 컴파일러는 여전히 고속 증분 컴파일에 최적화되어 있지 않습니다(Xcode 6.3 베타 기준).한편, 다음의 몇개의 기술을 사용해 Swift 컴파일 시간을 단축할 수 있습니다.

  • 앱을 프레임워크로 분할하여 재컴파일에 미치는 영향을 줄입니다.그러나 앱에서 주기적 종속성을 피해야 합니다.이 토픽의 상세한 것에 대하여는, 다음의 투고를 참조해 주세요.http://bits.citrusbyte.com/improving-swift-compile-time/

  • 프로젝트의 안정적이고 자주 변경되지 않는 부분에는 Swift를 사용하십시오.자주 변경해야 하는 기타 영역이나 컴파일/실행을 완료해야 하는 영역(거의 모든 UI 관련 항목)의 경우 혼합 및 일치 접근 방식을 사용하는 것이 좋습니다.

  • 'Xcode용 주입'을 사용하여 런타임 코드 주입을 시도

  • roopc 메서드를 사용합니다.http://roopc.net/posts/2014/speeding-up-swift-builds/

  • 명시적 캐스트로 힌트를 제공하여 빠른 유형 추론 엔진을 완화합니다.

신속한 배열과 사전 구축이 (특히 Ruby 배경에서 온 당신에게) 매우 인기 있는 원인인 것 같습니다.

var a = ["a": "b",
         "c": "d",
         "e": "f",
         "g": "h",
         "i": "j",
         "k": "l",
         "m": "n",
         "o": "p",
         "q": "r",
         "s": "t",
         "u": "v",
         "x": "z"]

이 문제가 해결되는 원인은 다음과 같습니다.

var a = NSMutableDictionary()
a["a"] = "b"
a["c"] = "d"
... and so on

디버깅 및 테스트에서는 다음 설정을 사용하여 컴파일 시간을 20분 정도에서2분 미만으로 단축해 주세요.

  1. 프로젝트 빌드 설정에서 "Optimization" 디버그를 "Fastest[-O3]" 이상으로 검색하십시오.
  2. 액티브 아키텍처 빌드 설정: 예
  3. 디버깅 정보 형식: DWARF
  4. 모듈 전체의 최적화: NO

프로젝트가 완성되기를 기다리며 수없이 많은 시간을 허비했지만, 작은 변화 하나만으로도 충분하다는 것을 깨닫고 테스트를 위해 30분을 더 기다려야 했습니다.이것은 나에게 효과가 있던 설정입니다.(아직 설정을 시험하고 있습니다)

단, 릴리스/아카이브가 iTunes Connect에 푸시하려면 적어도 "dSYM과의 전쟁"(애플리케이션을 감시하는 경우)과 "액티브 아키텍처 구축"(Build Active Architecture)을 "아니오"(NO)로 설정해야 합니다(여기서도 몇 시간을 낭비한 것으로 기억합니다).

컴파일러는 유형을 추론하고 확인하는 데 많은 시간을 소비합니다.따라서 유형 주석을 추가하면 컴파일러에 많은 도움이 됩니다.

연결된 함수가 많은 경우 다음과 같은 호출이 발생합니다.

let sum = [1,2,3].map({String($0)}).flatMap({Float($0)}).reduce(0, combine: +)

컴파일러가 어떤 의 컴파일러인지 데 .sum글자를 이 됩니다.유형을 추가하면 도움이 됩니다.간헐적인 단계를 별도의 변수로 끌어내는 것도 도움이 됩니다.

let numbers: [Int] = [1,2,3]
let strings: [String] = sum.map({String($0)})
let floats: [Float] = strings.flatMap({Float($0)})
let sum: Float = floats.reduce(0, combine: +)

숫자 타입의 CGFloat,Int" " "와 같은 "2는 다양한 수치 유형을 나타낼 수 있습니다.따라서 컴파일러는 어떤 것인지 컨텍스트에서 파악해야 합니다.

를 참조하는 데 시간이 많이 +피해야 합니다. 개의 " " " 를 합니다.+하는 것은 컴파일러가 이 구현되어 있는지 에 느립니다.+ 불러야 합니다.+ '...'를 var a: [Foo]append()★★★★★★★★★★★★★★★★★★★★

Xcode에서 컴파일 속도가 느린 함수를 검출하기 위한 경고를 추가할 수 있습니다.

타겟의 빌드 설정에서 기타 Swift Flags를 검색하여

-Xfrontend -warn-long-function-bodies=100

컴파일하는 데 100밀리초 이상 걸리는 모든 함수에 대해 경고합니다.

코드가는 Objective-C의 Swift를 설정할 수 .-enable-bridging-pchOther Swift Flags이를 통해 브리징 헤더는 한 번만 해석되며 결과(일시적인 "사전 컴파일된 헤더" 또는 "PCH" 파일)는 캐시되어 타깃 내의 모든 Swift 파일에 재사용됩니다.애플은 빌드 시간을 30% 단축한다고 주장했다.참조 링크:

메모: 이 기능은 Swift 3.1 이상에서만 사용할 수 있습니다.

Mac을 재부팅하면 이 문제가 해결됩니다.재부팅만으로 15분 빌드부터30초 빌드까지 늘렸습니다

정수 리터럴과 플로트 리터럴을 1개의 식에 혼재시켜도 컴파일 시간이 길어집니다.

1.0 + (1.0 + (1  * (1.0 + 1.0))) // 3429ms

1.0 + (1.0 + (1.0  * (1.0 + 1.0))) // 5ms

컴파일 시간 은 1000ms를 ..0정수 리터럴 뒤에 있습니다.

새로운 Xcode 6.3에서는 고속 컴파일 시간이 향상되었습니다.

컴파일러의 개량점

Swift 1.2 컴파일러는 보다 안정적이고 모든 면에서 성능을 향상시키도록 설계되었습니다.이러한 변경은 Xcode에서 Swift를 사용할 때 더 나은 경험을 제공합니다.가장 눈에 띄는 개선점에는 다음과 같은 것들이 있습니다.

증분 빌드

변경되지 않은 소스 파일은 기본적으로 더 이상 다시 컴파일되지 않으므로 대부분의 일반적인 경우 빌드 시간이 크게 단축됩니다.코드의 구조를 크게 변경해도 여러 파일을 재구축해야 할 수 있습니다.

실행 파일의 고속화

디버깅 빌드를 사용하면 바이너리가 상당히 빠르게 실행되며 새로운 최적화 기능을 통해 릴리스 빌드 성능이 더욱 향상됩니다.

컴파일러 진단 기능 향상

새로운 Fix-it과 함께 오류 및 경고 메시지가 명확해지기 때문에 Swift 1.2 코드를 올바르게 쓸 수 있습니다.

안정성 향상

가장 일반적인 컴파일러 크래시는 수정되었습니다.Xcode 에디터에서는 SourceKit 경고도 적게 표시됩니다.

유형 추론을 통해 엄청난 속도 저하를 야기할 수 있는 또 다른 사례가 있습니다.병합 연산자.

다음과 같은 줄 바꾸기:

abs(some_optional_variable ?? 0)

로.

abs((some_optional_variable ?? 0) as VARIABLE_TYPE)

컴파일 시간을 70대에서 13대로 끌어올렸다

Xcode 6.3.1에서는 아무것도 동작하지 않았습니다.Swift 파일 100개를 빌드 및/또는 인덱싱 중에 임의로 행업한 Xcode를 추가했을 때.모듈식 옵션을 시도해 봤지만 성공하지 못했습니다.

Xcode 6.4 Beta를 설치하고 사용하는 것이 실제로 효과가 있었습니다.

Speed Up Swift Compilation은 에게 마법처럼 작용하고 있습니다.컴파일 시간을 10분에서 3분으로 단축했다.

를 추가하는 동안 를 켜야 한다고 되어 있습니다.

/Xcode 8.2사용하고 있습니다.

언급URL : https://stackoverflow.com/questions/25537614/why-is-swift-compile-time-so-slow

반응형