Increasing D Compiler Speed by Over 75%

Walter Bright newshound2 at digitalmars.com
Wed Jul 31 16:32:08 PDT 2013


Thanks for doing this, this is good information.

On 7/31/2013 2:24 PM, Rainer Schuetze wrote:
> I have just tried yesterdays dmd to build Visual D (it builds some libraries and
> contains a few short non-compiling tasks in between):
>
> Debug build dmd_dmc: 23 sec, std new 43 sec
> Debug build dmd_msc: 19 sec, std new 20 sec

That makes it clear that the dmc malloc() was the dominator, not code gen.

> "std new" is the version without the "block allocator".
>
> Release build dmd_dmc: 3 min 30, std new 5 min 25
> Release build dmd_msc: 1 min 32, std new 1 min 40
>
> The release builds use "-release -O -inline" and need a bit more than 1 GB
> memory for two of the libraries (I still had to patch dmd_dmc to be
> large-address-aware).
>
> This shows that removing most of the allocations was a good optimization for the
> dmc-Runtime, but does not have a large, but still notable impact on a faster
> heap implementation (the VS runtime usually maps directly to the Windows API for
> non-Debug builds). I suspect the backend and the optimizer do not use "new" a
> lot, but plain "malloc" calls, so they still suffer from the slow runtime.

Actually, dmc still should give a better showing. All the optimizations I've put 
into dmd also went into dmc, and do result in significantly better code speed. 
For example, the hash modulus optimization has a significant impact, but I 
haven't released that dmc yet.

Optimized builds have an entirely different profile than debug builds, and I 
haven't investigated that.



More information about the Digitalmars-d-announce mailing list