Crystal Lang編譯器速度

我只是想知道Crystal編程語言的編譯速度。感覺比較慢：Crystal Lang編譯器速度

➜ ~/Code/crystal/crystal_scheduler (master ✘)✹✭ ᐅ time crystal build --release src/crystal_scheduler.cr 
34.64s user 1.10s system 93% cpu 38.174 total 
➜ ~/Code/crystal/crystal_scheduler (master ✘)✹✭ ᐅ time crystal build --release src/crystal_scheduler.cr 
36.11s user 0.83s system 93% cpu 39.465 total 
➜ ~/Code/crystal/crystal_scheduler (master ✘)✹✭ ᐅ time crystal build src/crystal_scheduler.cr 
8.09s user 0.89s system 181% cpu 4.956 total

代碼相對較小，兩個分片，兩個類。與我從Java中知道的其他編譯時間相比，這感覺好像很長時間。

我得到這個版本的編譯速度很慢，但混帳書指出：

這樣做的理由是不充分的優化，性能還是蠻不錯的，並提供快速的編譯時間，這樣你就可以使用幾乎就像是一名口譯員。

但8s覺得有點慢，聲稱你可以使用它「幾乎就像它是一個解釋器」。

我只是想知道如果 - 一）我的編譯是特別慢/編譯時間是正常 - B）如何比較其他語言在你的經驗

彙編統計：

Parse:        00:00:00.0007470 ( 0.25MB) 
Semantic (top level):    00:00:00.3968920 ( 36.08MB) 
Semantic (new):     00:00:00.0019210 ( 44.08MB) 
Semantic (type declarations):  00:00:00.0355760 ( 44.08MB) 
Semantic (abstract def check):  00:00:00.0012690 ( 44.08MB) 
Semantic (ivars initializers):  00:00:00.0094640 ( 44.08MB) 
Semantic (cvars initializers):  00:00:00.0394420 ( 44.08MB) 
Semantic (main):     00:00:00.6025030 (108.14MB) 
Semantic (cleanup):    00:00:00.0012750 (108.14MB) 
Semantic (recursive struct check): 00:00:00.0018930 (108.14MB) 
Codegen (crystal):     00:00:00.7354530 (140.27MB) 
Codegen (bc+obj):     00:00:33.2533520 (140.27MB) 
Codegen (linking):     00:00:00.3647440 (140.27MB)

我的系統：

➜ crystal -v 
Crystal 0.22.0 (2017-04-20) LLVM 4.0.0

硬件概述：

Model Name: MacBook Pro 
Model Identifier: MacBookPro11,1 
Processor Name: Intel Core i5 
Processor Speed: 2,8 GHz 
Number of Processors: 1 
Total Number of Cores: 2 
L2 Cache (per Core): 256 KB 
L3 Cache: 3 MB 
Memory: 16 GB

來源

2017-06-18 tpei

這聽起來有點慢對我來說，你可以使用'--stats'參數晶體編譯器以估算緩慢從何而來。在沒有任何細節或代碼的情況下調試「緩慢」是非常困難的，所以我不能做太多的事情，其他人可能會覺得這很慢並且很奇怪。 – RX14

我加了'--stats'輸出。我使用kemal.cr，但它基本上只有一個路由，沒有類，沒有任何東西。 – tpei

與其餘的pass相比，LLVM codegen階段看起來太長了。這是一個發佈版本嗎？例如，這是構建整個編譯器（這是更多代碼）的統計輸出，請注意每個部分相對於彼此花費的時間量：https://aww.moe/5n3ql4.txt – RX14

使用crystal build --no-debug my_code.cr可以提高編譯速度。

參見：Why Crystal use too much memory?和Crystal for large scale programs

另外，我建議你添加--progress標誌。

進度標誌添加更多關於編譯過程的信息，顯示在代碼相位上生成的每個文件的統計信息。

>>> crystal build -s --no-debug -p my_code.cr 
Parse:        00:00:00.0008560 ( 0.34MB) 
Semantic (top level):    00:00:00.2588280 ( 27.91MB) 
Semantic (new):     00:00:00.0018450 ( 35.91MB) 
Semantic (type declarations):  00:00:00.0263890 ( 35.91MB) 
Semantic (abstract def check):  00:00:00.0015270 ( 35.91MB) 
Semantic (ivars initializers):  00:00:00.0018980 ( 35.91MB) 
Semantic (cvars initializers):  00:00:00.0158470 ( 35.91MB) 
Semantic (main):     00:00:00.4168150 ( 60.10MB) 
Semantic (cleanup):    00:00:00.0010650 ( 60.10MB) 
Semantic (recursive struct check): 00:00:00.0008110 ( 60.10MB) 
Codegen (crystal):     00:00:00.3381910 ( 68.10MB) 
[12/13] [67/215] Codegen (bc+obj) 
     ~~~~~~~~ 
      (1)

（1）處理的文件量，可以在Crystal緩存目錄中看到這些文件。

順便說一句，我在不到30秒的時間內編譯了一個完整的琥珀項目，在舊的英特爾賽揚PC上有10個碎片。請勿在開發階段使用--release標誌，但在生產階段。（LLVM採取了很多時間做優化）

>>> cat /proc/cpuinfo | grep "model name" 
model name  : Intel(R) Celeron(R) 2957U @ 1.40GHz 
>>> shards list 
Shards installed: 
    * amber (0.1.3) 
    * radix (0.3.8) 
    * kilt (0.1.0) 
    * slang (1.6.1) 
    * redis (1.8.0) 
    * quartz-mailer (0.1.0) 
    * kilt (0.1.0) 
    * smtp (0.1.0) 
    * granite_orm (0.6.2) 
    * kemalyst-validators (0.2.0) 
    * db (0.4.2) 
    * sqlite3 (0.8.2) 
    * db (0.4.2) 
>>> time crystal build -p src/app.cr -o app --no-debug 
real 0m24.320s 
user 0m26.700s 
sys  0m1.437s 
>>> time crystal build -p src/app.cr -o app --no-debug   
real 0m6.225s 
user 0m5.727s 
sys  0m0.970s

來源

2017-07-21 12:33:45

另請參閱：[爲什麼編譯器速度很慢並消耗大量內存]（https://github.com/crystal-lang/crystal/issues/4864） –

Crystal Lang編譯器速度

回答

相關問題