On Thursday, 21 March 2019 at 13:54:44 UTC, jmh530 wrote:
> On Thursday, 21 March 2019 at 12:12:00 UTC, Seb wrote:
>> [snip]
>>
>> OK. Thanks a lot for your support!
>> This is now in master and coming to your nearest DMD nightly and DMD 2.086:
>>
>>
>> https://dlang.org/changelog/pending.html#std-all
>
> Nice.
>
> Where it says
> "The baseline cost for import std; is less than half a second (varying from system to system) and work is in progress to reduce this overhead even further."

That's just a very negative estimate. On my machine it's less than 0.2s and the released DMD is still compiled with DMD - just imagine how fast it would be when we finally start shipping a DMD compiled with LDC.

> It would be interesting if there was a way to speed it up specifically for something like run.dlang.org as well.

- compile DMD with LDC
- instantiate more modules lazily in Phobos

At the moment the entire std.uni trie is loaded and parsed, because IIRC std.net.curl has a struct that somewhere uses a type which through multiple layer's of inference depends on an instantiated std.uni. Potential fixes:

- make struct instantiation lazy (pretty hard as it touches a lot of DMD)
- make std.uni's table lazy (building them at CTFE is still pretty expensive)

Other ideas:
- fully lazy imports (this can work for selective and static imports)
- CTFE caching

I presume that's what you were thinking about. In theory, there's no need for the compiler to re-instantiate all the Phobos if it already has done so. There was quite a bit of work by Dmitry on this one, but somehow it died:

https://github.com/dlang/dmd/pull/7843

- do sth. like Vladimir's forking DMD compiler (i.e. serialize the compiler's state to disk)

https://blog.thecybershadow.net/2018/11/18/d-compilation-is-too-slow-and-i-am-forking-the-compiler

tl;dr: for now the easiest and still low-hanging fruit is to improve the compilation time of Phobos further.

Vladimir has written a great tool which helps with this:

https://github.com/CyberShadow/dmdprof