While I see you already figured out your answer, since you revived this ancient
thread, I can perhaps say some other things that might be helpful for fast
compiles. I do this in my $HOME/.config/nim/nim.cfg:
# Ideally, each Nim compiler flag would have an associated defineSymbol,
BUT we
# can: git log -p compiler/condsyms.nim lib/system.nim & find NimMinor
edits and
# then search forward/backward for defineSymbol instead to get:
# surrogate for 1.0.0 nimMacrosGetNodeId
# surrogate for 1.2.0 nimHasInvariant
# surrogate for 1.4.0 nimHasCastPragmaBlocks
# surrogate for 1.6.0 nimHasEffectsOf
# surrogate for 1.7.0 nimHasEnforceNoRaises
# nimHasOutParams >20221006 (10-09 intro'd atomics) mm=markAndSweep for
tcc
# This is fragile if any such features vanish, but avoids NimScript
slowness.
#NOTE 2023-12-14: cc=tcc breaks nimsuggest w/nil destructor assert, but
adding
# '-d=release' to 'args' in autoload/nim/suggest/manager.vim fixes it.
@if release or danger: cc=gcc @else cc=tcc @end # Rapid edit-compile-test
.
.
.
@if big chain of various compilers
.
.
.
@else
@elif tcc: # tcc for debugging
line_dir=off # infinite loops tcc lately;
github.com/nim-lang/Nim/pull/23488
@if threads: tlsEmulation=on @end
passL="-lm"
@if nimHasNoReturnError: mm=arc @else
@if nimHasCastExtendedVm: @else # <2.1 broke mm:arc on tcc for a
time
@if nimHasEffectsOf: mm=markAndSweep # >= 1.6.0; Use mm to nix
deprecation
@else: gc=markAndSweep # else use --gc
@end
@end
@end
@end
Run
To save some more time, NimScript is slower than `nim.cfg` parsing/eval'ing.
So, for even faster compiles, I also typically rename
`/usr/lib/nim/config/config.nims` to `/usr/lib/nim/config/config.nims-` (it
does almost nothing anyway, and I also almost never use the `nim cpp` backend).
With all that, I get compile times for "the empty .nim" around 113.21 +- 0.19
ms on just the P-cores of my laptop (i7-1370P). Obviously the more you
import/compile, the longer it takes.
$ tim 'rm -rf ~/.cache/nim/*; nim c j >/n 2>&1'
97.9 +- 1.6 μs (AlreadySubtracted)Overhead
(1.1321 +- 0.0019)e+05 μs rm -rf ~/.cache/nim/*; nim c j >/n 2>&1
Run
`tim` is [bu/tim](https://github.com/c-blake/bu/blob/main/doc/tim.md) and "/n"
is a symlink to `/dev/null` since I type it _way_ to often and also I have
`time-unit = "μs"` in my `~/.config/tim`.
Oh, and just to support my `config.nims-` point, I renamed it back to
`config.nims` and then re-ran the above to get:
tim 'rm -rf ~/.cache/nim/*; nim c j >/n 2>&1'
99.7 +- 1.5 μs (AlreadySubtracted)Overhead
(1.4926 +- 0.0061)e+05 μs rr ~/.cache/nim/*; nim c j >/n 2>&1
Run
So, that `/usr/lib/nim/config/config.nims` is costing about `(1.4926 +-
0.0061)-(1.1321 +- 0.0019)` or (using [a little
wrapper](https://github.com/SciNim/Measuremancer/pull/12) I have around
@Vindaar's [Measuremancer](https://github.com/SciNim/Measuremancer)) `36.05 +-
0.64 ms`, at least on that machine, or in this case around a `1.3184 +- 0.0058`
(very best case) speed ratio. Again, only for compiling the empty file - so a
minimal case { unless you do one of those "no system.nim" style builds }.
These times may seem trivial, but they add up when you have wrappers that
generate code, compile it and run it, e.g. the awk-like row-processor
[rp](https://github.com/c-blake/bu/blob/main/doc/rp.md) or when you are
iterating on some [cligen](https://github.com/c-blake/cligen) help message text.
