I just upgraded from DMD 2.065.0 (so about 2 years old) to 2.070.0, and noticed a difference in compilation speed. I'll detail what I see, in case it's interesting, but really I just want to ask: What should I expect? I know that DMD is now selfhosting, and I know there's a tradeoff between compilation speed and speed of generated code. Or maybe it's just a tweak to default compiler options.
So maybe this is completely known.

What I see:
DMD 32 running on Windows 10, on my laptop that's quite a few years old.
Random tiny single-file .d program; I'm looking at what happens when I make a change and then run the program (with or without "-unittest").

On 2.065.0: This takes around 1.9 seconds. On 2.070.0: This takes around 3.6 seconds.

I really don't want to trigger an investigation if this is just an anomaly - I'm still quite happy with 4 seconds to compile and run unit tests. I mainly mention it in case it's an interesting surprise.

On Thursday, 11 February 2016 at 05:38:54 UTC, Andrew Godfrey wrote:
> I just upgraded from DMD 2.065.0 (so about 2 years old) to 2.070.0, and noticed a difference in compilation speed. I'll detail what I see, in case it's interesting, but really I just want to ask: What should I expect? I know that DMD is now selfhosting, and I know there's a tradeoff between compilation speed and speed of generated code. Or maybe it's just a tweak to default compiler options.
> So maybe this is completely known.
>
> [...]

I don't think it's unexpected, though something to work on beating back.

On Thursday, 11 February 2016 at 05:38:54 UTC, Andrew Godfrey wrote:
> I just upgraded from DMD 2.065.0 (so about 2 years old) to 2.070.0, and noticed a difference in compilation speed. I'll detail what I see, in case it's interesting, but really I just want to ask: What should I expect? I know that DMD is now selfhosting, and I know there's a tradeoff between compilation speed and speed of generated code. Or maybe it's just a tweak to default compiler options.
> So maybe this is completely known.

Check this:
http://digger.k3.1azy.net/trend/

On Thursday, 11 February 2016 at 08:37:29 UTC, Andrea Fontana wrote:
> Check this:
> http://digger.k3.1azy.net/trend/

Cool, why did the peak heap size during compilation drop from approx. 180MB to 30MB?

On Thursday, 11 February 2016 at 08:46:19 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 11 February 2016 at 08:37:29 UTC, Andrea Fontana wrote:
>> Check this:
>> http://digger.k3.1azy.net/trend/
>
> Cool, why did the peak heap size during compilation drop from approx. 180MB to 30MB?

Zooming on graph you can see that the improvement was due to this:
https://github.com/D-Programming-Language/dmd/pull/4923

On Thursday, 11 February 2016 at 08:57:22 UTC, Andrea Fontana wrote:
> Zooming on graph you can see that the improvement was due to this:
> https://github.com/D-Programming-Language/dmd/pull/4923

But why? Is it using the GC, or what?

On Thu, 11 Feb 2016 09:04:22 +0000, Ola Fosheim Grøstad wrote:

> On Thursday, 11 February 2016 at 08:57:22 UTC, Andrea Fontana wrote:
>> Zooming on graph you can see that the improvement was due to this: https://github.com/D-Programming-Language/dmd/pull/4923
> 
> But why? Is it using the GC, or what?

From dmd/src/mars.d:

version (GC)
{
}
else
{
  GC.disable();
}

And the compiler is still not compiled with -version=GC by default, as far as I can determine.

The talks I've heard suggested that DMD may hide pointers where the GC can't find them (a relic from the C++ days), producing crashes and memory corruption when the GC is enabled. So the GC was disabled for stability.

That trend of memory reduction holds for the other samples, so this is probably something to do with the compiler rather than, say, writefln changing implementation to require much less memory to compile. But I'm not sure what might have caused it.

On Thursday, 11 February 2016 at 08:37:29 UTC, Andrea Fontana wrote:
>
> Check this:
> http://digger.k3.1azy.net/trend/

Very nice!