Hacker News new | ask | show | jobs
by cb321 1457 days ago
As with most things, "it depends". If you compile very macro compile-time virtual-machine heavy code that can be slow. If you compile to the c++ backend then that backend process can be slow. If you invoke some macro that generates mountains of Nim code translated to continents of C code it can be slow. If you use the default `nim.cfg` that has gcc -Og it can take a lot longer than gcc -O0, for example. Meanwhile, if you use the `tcc` backend even without incremental compilation it can be close to immediate feedback:

    $ touch foo.nim
    $ /usr/bin/time nim c foo.nim
    CC: ../usr/lib/nim/lib/std/private/digitsutils.nim
    CC: ../usr/lib/nim/lib/system/dollars.nim
    CC: ../usr/lib/nim/lib/system.nim
    CC: foo.nim
    Hint: gc: refc; opt: none (DEBUG BUILD, `-d:release` generates faster code)
    36891 lines; 0.154s; 39.434MiB peakmem; proj: /tmp/foo.nim; out: /tmp/foo [SuccessX]
    0.24user 0.02system 0:00.27elapsed 101%CPU (0avgtext+0avgdata 44360maxresident)k
    0inputs+0outputs (0major+13676minor)pagefaults 0swaps
(I point my default backend compiler to tcc in my $HOME/.config/nim/nim.cfg.) There are some more details in this nim forum thread: https://forum.nim-lang.org/t/8677

Unless your standards are "single digit milliseconds per file like tcc itself, please!", 240 ms is not so bad. (EDIT: And this is just on some 2016-era Intel i7-6700k box, not some liquid helium cooled 10 GHz whatever.)