【问题标题】:Crystal Lang Compiler SpeedCrystal Lang 编译器速度
【发布时间】:2017-06-18 10:23:09
【问题描述】:

我只是想知道 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 book 指出:

这样做的原因是没有完全优化的性能是 仍然相当不错并且提供了快速的编译时间,所以你可以使用 水晶命令几乎就像一个解释器。

但是 8s 声称你可以“几乎就像是一个解释器一样”使用它感觉有点慢。

我只是想知道如果 - 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

【问题讨论】:

  • 这听起来有点慢,你可以使用水晶编译器的--stats 参数来估计慢的来源。在没有任何细节或代码的情况下很难调试“慢”,所以我无能为力,其他说它这么慢似乎很奇怪。
  • 我添加了--stats 输出。我正在使用 kemal.cr,但它基本上只有一条路线,没有课程,什么都没有。
  • 与其他通道相比,LLVM 代码生成阶段看起来太长了。那是发布版本吗?例如,这是我构建整个编译器的统计输出(其中包含更多代码),请注意每个部分相对于彼此花费的时间:aww.moe/5n3ql4.txt
  • 有趣...是的,这是一个发布版本

标签: crystal-lang


【解决方案1】:

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

请参阅:Why Crystal use too much memory?Crystal for large scale programs

另外,我建议你添加--progress标志。

进度标志添加了有关编译过程的更多信息,显示了在 codegen 阶段生成的每个文件的统计信息。

>>> 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
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-12-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多