DMD compilation speed

[w0rp via Digitalmars-d]

On Monday, 30 March 2015 at 22:55:50 UTC, H. S. Teoh wrote:
> On Mon, Mar 30, 2015 at 10:39:50PM +0000, lobo via 
> Digitalmars-d wrote:
>> On Sunday, 29 March 2015 at 23:14:31 UTC, Martin Krejcirik 
>> wrote:
>> >It seems like every DMD release makes compilation slower. 
>> >This time I
>> >see 10.8s vs 7.8s on my little project. I know this is 
>> >generally
>> >least of concern, and D1's lighting-fast times are long gone, 
>> >but
>> >since Walter often claims D's superior compilation speeds, 
>> >maybe some
>> >profiling is in order ?
>> 
>> I'm finding memory usage the biggest problem for me. 3s speed 
>> increase
>> is not nice but an increase of 500MB RAM usage with DMD 2.067 
>> over
>> 2.066 means I can no longer build one of my projects.
> [...]
>
> Yeah, dmd memory consumption is way off the charts, because 
> under the
> pretext of compile speed it never frees allocated memory. 
> Unfortunately,
> the assumption that not managing memory == faster quickly 
> becomes untrue
> once dmd runs out of RAM and the OS starts thrashing. Compile 
> times
> quickly skyrocket exponentially as everything gets stuck on I/O.
>
> This is one of the big reasons I can't use D on my work PC, 
> because it's
> an older machine with limited RAM, and when DMD is running the 
> whole box
> slows down to an unusable crawl.
>
> This is not the first time this issue was brought up, but it 
> seems
> nobody in the compiler team cares enough to do anything about 
> it. :-(
>
>
> T

I sometimes think DMD's memory should be... garbage collected. I 
used the forbidden phrase!

Seriously though, allocating a bunch of memory until you hit some 
maximum threshold, possibly configured, and freeing unreferenced 
memory at that point, pausing compilation while that happens? 
This is GC. I wonder if someone enterprising enough would be 
willing to try it out with DDMD by swapping malloc calls with 
calls to D's GC or something.