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编译器速度

回答

相关问题