Compilation time and live reload

[Radosław Bułat]

Hello.

One thing I'm worried about Crystal is compilation time. Typical medium ruby (rails) application has tens of tousands lines of code and uses tens of gems. One legacy app I've worked with has ~50k lines of ruby code + ~30k lines of templates (haml, erb) , 215 gems. Application during startup loads almost 400k lines of ruby code ($LOADED_FEATURES.map { |feature| File.read(feature).lines.count rescue 0 }.sum).

Compiling crystal compiler takes 21 seconds (i5 2.6GHz, 8 GB RAM, ssd) on my machine:

    time CRYSTAL_CONFIG_PATH=`pwd`/src ./bin/crystal build  -o .build/crystal src/compiler/crystal.cr


    Using compiled compiler at .build/crystal


    real  0m19.017s
    user  0m21.966s
    sys 0m4.481s


    $ find src/compiler/ -name "*.cr" | xargs wc -l | tail -1
   36834 total

Compiling all specs take 1m30s...

Development with rails is very responsive. Change one line, reload page and voilà. If programmer will have to wait more than 5s to recompile crystall app it will sucks :/. Is it a thing I should worry about or not?

[Ryan Gonzalez]

Try using a pre-built version of Crystal. Those are built in release mode, so the compile times drop drastically. For me, it takes about 10 secs, which isn't much longer than the equivalently-sized C++ application.

--
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

[Ary Borenszweig]

Yes, a pre-compiled binary (which is compiled with --release) helps a lot.

In any case, the truth is that it worries us too. We know that compile times will grow (linearly, we think) relative to the size of the application. And since we don't do incremental compilation that time can't be lowered (actually, we save some .bc/.o files from the previous compilation and use those, improving codegen time, but type inference time is always the same).

We have some ideas on how to improve this. Most importantly, we believe that with time/money/man-power it can be solved. There's the case of V8, where everyone though Javascript, it being dynamic and all, couldn't be optimized to near-native performance, but they did it. Our case is similar: there's this new technology and nobody spent enough time trying to think of a way to optimize the compiler or do incremental compilation. Everything is possible :-)

Another possibility is to slowly add types to a library to improve compile times, somehow. This could work: you can start with a prototype and once it matures you evolve it so it provides better error messages and it can be pre-compiled. But we'd like to leave that option as a last resort.

--
You received this message because you are subscribed to the Google Groups "Crystal" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crystal-lang...@googlegroups.com.
To post to this group, send email to crysta...@googlegroups.com.
Visit this group at http://groups.google.com/group/crystal-lang.
To view this discussion on the web visit https://groups.google.com/d/msgid/crystal-lang/4EA9D34D-1952-4BB3-B839-2F34AB2B7B5C%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Ary Borenszweig         Manas Technology Solutions
[ar.phone]                      5258.5240       #ARY(279)
[us.phone]                      312.612.1050    #ARY(279)
[email]                         aboren...@manas.com.ar
[web]                           www.manas.com.ar

[Ryan Gonzalez]

Well:

1. Initial compilation isn't as important. It still is, but, at the same time, it only happens once.

2. Incremental compilation. *This* is the big one. I had the idea that Crystal could serialize the AST (AFTER type inference and all the inlining and such complete) of each module into a binary format. Then, before generating the LLVM code, Crystal would check if the module hasn't been changed at all and, if so, avoid regenerating the LLVM and just use the same object file.