> on a small project
Yes, and things change for big projects.
@amalek @cblake > if you want to speed up compile times you can use tcc
unfortunately tcc doesn't work on OSX, see
[https://github.com/wheineman/nrpl/issues/16](https://github.com/wheineman/nrpl/issues/16)
besides, this would come at a cost of runtime performance (but would still be
good for
The biggest thing that would reduce compile time is putting the compiler on a
(quantum?) supercomputer in the cloud...
@timothee - @amalek beat me to the punch, but user-visible compilation time is
very sensitive to backend compiler/gcc options. Consider two invocations
compiling my [cligen](https://github.com/c-blake/cligen) test suite (30
programs with somewhat complex macros running at compile-time):
As tewtzel59 said, Nim usually compiles to C (and I guess that's what most
people who program in Nim use). Even if modules were to be added to C, it
wouldn't happen before
2022[[1](http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2086.htm)], which is
when the new standard will probably be
The biggest and most pressing issue wrt compilation speed is the unfinished
`--symbolFiles` feature. "symbolfiles" has become my term for "incremental
compilation", its latest incarnation uses a database to store intermediate
compilation fragments on a module granularity. Only modules that have
In the last few months I haven't really kept up with the C++ world, so I hadn't
heard of this new feature. I see it was in fact proposed way back in 2014?
(According to Wikipedia)...
Anyway, for this to work, several things must be considered
* What about **C**? Nim often compiles to C, not
Nim benefit from upcoming C++ modules to speedup compilation times? eg by
using C++ import foo instead of re-declaring each needed symbol This would
speedup compilation, eg in non-separate compilation model, but possibly also
separate compilation model too (eg with compilation server)
