DMD compilation speed

[lobo via Digitalmars-d]

On Wednesday, 1 April 2015 at 02:54:48 UTC, Jake The Baker wrote:
> On Tuesday, 31 March 2015 at 19:27:35 UTC, Adam D. Ruppe wrote:
>> On Tuesday, 31 March 2015 at 19:20:20 UTC, Jake The Baker 
>> wrote:
>>> As far as memory is concerned. How hard would it be to simply 
>>> have DMD use a swap file?
>>
>> That'd hit the same walls as the operating system trying to 
>> use a swap file at least - running out of address space, and 
>> being brutally slow even if it does keep running.
>
> I doubt it. If most modules are sparsely used it would improve
> memory usage in proportion to that.
>
> Basically if D would monitor file/module usage and compile areas
> that are relatively independent it should minimize disk usage.
> Basically page out stuff you know won't be needed. If it was
> smart enough it could order the data through module usage and
> compile the independent ones first, then only the ones that are
> simple dependencies, etc).
>
> The benefits to such a system is that larger projects get the
> biggest boost(there are more independent modules floating 
> around.
> Hence at some point it becomes a non-issue.

I have no idea what you're talking about here, sorry.

I'm compiling modules separately already to object files. I think 
that helps reduce memory usage but I could be mistaken.

I think the main culprit now is my attempts to (ab)use CTFE. 
After switching to DMD 2.066 I started adding `enum val=f()` 
where I could. After reading the discussions here I went about 
reverting most of these back to `auto val=<blah>` and I'm 
building again :-)

DMD 2.067 is now maxing out at ~3.8GB and stable.

bye,
lobo