4 ms·

I've not used it for anything too big, but D compiles incredibly fast.

kbwt 8y ago
Recent article regarding D compile times: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ https://blog.thecybershadow.net/2018/11/18/d-compilation-is-...
gmueckl 8y ago
It is very fast for certain projects, but link times on some can make up for that. I have a toy program using vibe.d that takes around 1s to compile and 10s to link. I could probably make that faster by switching to gold, but I didn't yet.
- e12e 8y ago
  I'm not sure how anything over 100ms could be considered "fast compile" for a toy program... Basically Pascal, or simple c compilers like tcc should be the benchmark imnho. That's not to say I don't allow for trade-offs.. I gladly trade some milliseconds (or, grudgingly seconds) for features.
  - gmueckl 8y ago
    Most of the compile time of that particular program is spent parsing HTML templates and converting them to D code. This is all done by D code provided by a library that runs at compile time as part of a template function instantiation in my code. So the compile time is inflated a bit in this case.
kbwt 8y ago
On big projects, linking times are really the bottleneck. Sure, incremental linkers exist [1], but all of them tend to do O(n) work on every invocation. Source control software, even developed explicitly to scale [2], behaves the same way. Makefiles as well; Tup [3] tries to solve this, in vain since the linking step is still holding everything up. There is so much inherent inability to scale built into our tools. So on big projects everything grinds to a halt as you cannot buy enough developers and hardware to keep up with O(n^2) forever. [1] MSVC cl, GNU gold [2] git: http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html [3] tup: http://gittup.org/tup/manual.html http://gittup.org/tup/manual.html
- earenndil 8y ago
  This can be solved by putting individual components into shared libraries.
  - kbwt 8y ago
    But then you pay the cost every single time on startup, unless your components barely interact.

kbwt 8y ago

Recent article regarding D compile times: https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler/ https://blog.thecybershadow.net/2018/11/18/d-compilation-is-...

gmueckl 8y ago

It is very fast for certain projects, but link times on some can make up for that. I have a toy program using vibe.d that takes around 1s to compile and 10s to link. I could probably make that faster by switching to gold, but I didn't yet.

e12e 8y ago
I'm not sure how anything over 100ms could be considered "fast compile" for a toy program... Basically Pascal, or simple c compilers like tcc should be the benchmark imnho. That's not to say I don't allow for trade-offs.. I gladly trade some milliseconds (or, grudgingly seconds) for features.
- gmueckl 8y ago
  Most of the compile time of that particular program is spent parsing HTML templates and converting them to D code. This is all done by D code provided by a library that runs at compile time as part of a template function instantiation in my code. So the compile time is inflated a bit in this case.

kbwt 8y ago

On big projects, linking times are really the bottleneck. Sure, incremental linkers exist [1], but all of them tend to do O(n) work on every invocation. Source control software, even developed explicitly to scale [2], behaves the same way. Makefiles as well; Tup [3] tries to solve this, in vain since the linking step is still holding everything up. There is so much inherent inability to scale built into our tools. So on big projects everything grinds to a halt as you cannot buy enough developers and hardware to keep up with O(n^2) forever. [1] MSVC cl, GNU gold [2] git: http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html http://lkml.iu.edu/hypermail/linux/kernel/0504.0/2022.html [3] tup: http://gittup.org/tup/manual.html http://gittup.org/tup/manual.html

earenndil 8y ago
This can be solved by putting individual components into shared libraries.
- kbwt 8y ago
  But then you pay the cost every single time on startup, unless your components barely interact.