On Friday, 30 March 2018 at 20:40:16 UTC, Stefan Koch wrote:
On Friday, 30 March 2018 at 20:17:39 UTC, Andrei Alexandrescu
wrote:
On 3/30/18 12:12 PM, Atila Neves wrote:
Fast code fast, they said. It'll be fun, they said. Here's a
D file:
import std.path;
Yep, that's all there is to it. Let's compile it on my laptop:
/tmp % time dmd -c foo.d
dmd -c foo.d 0.12s user 0.02s system 98% cpu 0.139 total
Could be faster.
That... doesn't seem too fast to me. But wait, there's more:
/tmp % time dmd -c -unittest foo.d
dmd -c -unittest foo.d 0.46s user 0.06s system 99% cpu
0.525 total
Not fast. We need to make -unittest only affect the built
module. Even though it breaks certain uses of
__traits(getUnittests). No two ways about it. Who can work on
that?
Andrei
unittests by nature usually have a short list of dependencies
and therefore their compilation can be parallelized.
There are many performance leaks we can fix, before we need to
think about breaking useful features!
No one wants to run the std.regex's testsuite when they pass
-unittest or instantiate and run all tests for all Tuple
combinations present.
If you can make dmd so fast that this happens unnoticed, that
would be amazing, otherwise I suggest we don't run Phobos's
templated unittests in user-code.
