Hello !
I'm using Nim to make a small game engine and a few games. However, as the engine has grow, the compile time has increased by a lot.
Currently, the project has 10102 lines of Nim code (excluding comments and empty lines) and takes about 10 seconds to compile. While this is very impressive for a language without incremental compilation, it makes iterating very slow (I'm working with 1.6.12, refc and the cpp backend because of a cimgui dependency and planning to switch to orc at some point).
Moreover, I had another project that used libp2p and where compilation times where so unbearable slow (about 30 seconds) that I decided to switch to go as the whole libp2p code needed to get recompiled every time.
While IC is in the works, do you have any tips on how to speed up compilation times / alleviate the issue ?
Maybe a way to compile parts of a project into DLL files as a primitive IC ?
Or maybe using hot reloading, I don't know if it helps ?
Or is it possible to use IC with devel using some undocumented compiler flag ?
You could also look at using a caching c compiler like zapcc
I have no idea why you gave such advice? For latest version of my SDT tool, Nim compiler takes 42 seconds, and gcc backend 3, so 45 s total. On modern AMD Ryzen 9 5900HX, 8 core, 64 GB. So what may zapcc improve? But well, I may compile two or three times each hour when I work on that project, so really no problem. And I can live without NimSuggest support. For IC, the Crystal guys have also problems with that, seems to be really hard for a language with generics, macros and type inference. See https://dev.to/asterite/incremental-compilation-for-crystal-part-1-414k. And please don't call me dude again, German translation seems to be "Alter", and when someone calls me that on the street, they may get some serious trouble.
And please don't call me dude again, German translation seems to be "Alter", and when someone calls me that on the street, they may get some serious trouble.
Dude, chill.
From your post, I believe you are using Nim on Windows. If not, disregard.
Well, if you're using gcc, especially the winlibs.com distribution, your poor compilation time could be down to that gcc/mingw64 distribution. I currently use the gcc/mingw64 distribution of niXman mingw-builds-binaries which is up to 2.5x faster.
Another solution is to switch to llvm/clang. Here, llvm/clang is up to 3.8x faster than the gcc/mingw64 winlibs.com distribution.
The tcc compiler I stopped testing with Nim a while ago, as there are no plans to support it anymore.
I tried using clang and I'm getting about the same times. tcc does not work with Nim sadly.
I'll try using the compiler you provided.
I tried using clang
I begin to wonder if I should really miss something? It was my strong feeling, that whenever compile times are more than a few secs, then 90% of the time is consumed by the Nim compiler, and only 10% by C backend? Has that changed? Because Nim compiler is single threaded, and has to process macros and generics and all that. C backend should use all cores in parallel, and only compile modified files.
All cache is deleted before each test run and compilation is always done with the same nim.exe resulting from csources_v2.
Commands used to build the compiler:
@ECHO OFF
SET CC=--cc:gcc|clang
RMDIR /S /Q E:\Nim\nimcache
COPY /Y E:\Nim\bin\nim_csources_86742fb02c6606ab01a532a0085784effb2e753e.exe E:\Nim\bin\nim.exe
call timecmd koch boot -d:release --skipUserCfg --skipParentCfg %CC%
Intel i7-4810MQ, Windows 10 64-bit.
@vanyle - I always use the mob branch, but virtually never have trouble on Linux x64 with nim c --cc=tcc --mm=markAndSweep except that the code runs more slowly in exchange for the faster compile times, much as would be the case for gcc -O0.
I will reiterate my recommendation for gcc -O0 which you may not have noticed. I got like 4..5X speed-ups from that 1 character change in your nim.cfg on the reproducible benchmark in the Forum thread I already linked to.
Or maybe speeding up the C compile won't help you at all. The compiler has a virtual machine that can, of course, do loops and slow down compile times as much as you want within its limits (which you can even increase). Everything always depends on lots of workload assumptions.
Please find some nim bench compiler tool which could help with the topic: https://github.com/inv2004/bench_nim_build
Clang is definitely visible faster forvnim compilation, GCC produces faster code sometimes
You can also use dynamically linked libraries in Nim to reduce compile times. For your libp2p example it could probably be greatly sped up by compiling the libp2p portion into a dynlib.
I think you could use this technique https://nim-lang.org/docs/manual.html#userminusdefined-pragmas-pragma-pragma or maybe https://github.com/treeform/genny