2017-04-17 22 views
3

我有一個開源項目,並在項目文件的計數器超過40配置爲「釋放」時,Swift構建時間過長?

我建項目時的配置是Debug和編譯時間爲2m22s。 而且我也用BuildTimeAnalyzer,最長的時間全是28ms

但是,當我使用Release配置構建項目時,它在1小時內停留在Compile Swift source files

我不知道這件事,請幫助我。

+1

請提及您使用的是哪種Xcode版本/ swift版本? –

+0

我使用xcode 8.2和swift 2.3和swift 3. –

+0

由於它是一個「開源項目」,您能否提供該項目的源代碼? – kennytm

回答

0

試試這個.... Build Settings下 - >Swift Compiler - Code GenerationRelease選擇SWIFT_OPTIMIZATION_LEVEL = -Owholemodule。然後在Other Swift Flags下輸入-Onone。這樣做會在我的項目中浪費大量時間。

2

在DEBUG構建中,如果將每個函數花費的所有時間加起來,則會得到大約7s。這些數字並不完全相加 - 你花了142s來構建整個事情,但這些功能只需要大約7s以上的時間來編譯?

這是因爲這些時間只是檢查每個函數體的類型。在Swift frontend有三個標誌,你可以使用:

  1. -Xfrontend -debug-time-compilation
  2. -Xfrontend -debug-time-function-bodies
  3. -Xfrontend -debug-time-expression-type-checking

讓我們使用最先看到全貌。選擇一個緩慢的文件,說Option.swift,並期待:

===-------------------------------------------------------------------------=== 
           Swift compilation 
===-------------------------------------------------------------------------=== 
    Total Execution Time: 30.5169 seconds (43.6413 wall clock) 

    ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Name --- 
    23.5183 (80.1%) 0.7773 (67.6%) 24.2957 (79.6%) 34.4762 (79.0%) LLVM output 
    3.7312 (12.7%) 0.0437 ( 3.8%) 3.7749 (12.4%) 5.4192 (12.4%) LLVM optimization 
    1.8563 ( 6.3%) 0.2830 (24.6%) 2.1393 ( 7.0%) 3.1800 ( 7.3%) IRGen 
    0.2026 ( 0.7%) 0.0376 ( 3.3%) 0.2402 ( 0.8%) 0.4666 ( 1.1%) Type checking/Semantic analysis 
... <snip> ... 
    29.3665 (100.0%) 1.1504 (100.0%) 30.5169 (100.0%) 43.6413 (100.0%) Total 

原來這不是斯威夫特是緩慢的,但LLVM!所以沒有必要考慮類型檢查時間。我們可以進一步檢查爲什麼LLVM使用-Xllvm -time-passes慢,但它不會給我們有用的信息,它只是說X86 Assembly/Object Emitter大部分時間。

讓我們退後一步,並檢查哪些文件佔據了大部分時間來編譯:

Option.swift    30.5169 
Toolbox.swift   15.6143 
PictorialBarSerie.swift 12.2670 
LineSerie.swift   8.9690 
ScatterSerie.swift  8.5959 
FunnelSerie.swift   8.3299 
GaugeSerie.swift   8.2945 
... 

半分鐘在Options.swift度過的。這個文件有什麼問題?

  1. 您有一個巨大的結構,有31個成員。單獨編譯該結構需要11秒。
  2. 你有一個巨大的枚舉,有80個變種。單獨編譯此枚舉需要7秒。

第一個問題很容易修復:改爲使用final class第二個問題不會有一個簡單的解決方法(我沒有看到任何時間改善與替代品,例如用類層次結構取代枚舉)。所有其他慢速文件都有類似的問題:結構龐大,枚舉大。

只需更換所有structfinal class就足以將編譯時間從「超過幾小時,仍然編譯」到「2.5分鐘」。


另請參閱Why Choose Struct Over Class?。您的「結構」可能不符合struct s。

請注意,從struct更改爲類會改變用戶代碼的語義,因爲類具有引用語義。

+0

非常感謝你,你救了我!!!!! –

相關問題