Crystal Lang 编译器速度

Crystal Lang Compiler Speed

我只是想知道 Crystal 编程语言的编译器速度。感觉比较慢:

➜ ~/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 了解到的其他编译时间相比,这感觉很长。

我知道发布编译很慢,但是 git 书中指出:

The reason for this is that performance without full optimizations is still pretty good and provides fast compile times, so you can use the crystal command almost as if it were an interpreter.

但是8s说可以用感觉有点慢"almost as if it were an interpreter".

我只是想知道是否 - a) 我的编译特别慢/编译时间正常 - 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

使用crystal build --no-debug my_code.cr稍微提高编译速度。

参见:Why Crystal use too much memory? and 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 缓存目录中看到这些文件。

顺便说一句,我在一台旧的 Intel Celeron PC 上用 10 个分片在不到 30 秒的时间内编译了整个 Amber 项目。不要在开发阶段使用 --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