On Wednesday, 12 August 2015 at 00:44:19 UTC, Walter Bright wrote:

30% is a problem, but not a disaster. Some mitigating factors:

1. I believe that there is an excessive number of template instantiations going on. This is borne out by the profile results you supplied (thank you). I.e. it should not be necessary to instantiate a template in order to determine if it has already been instantiated.

Yes, but it's seems a bit unrealistic to rewrite template instantiation and make a ddmd switch in one release.

2. Not much effort has been expended in profiling dmd in a while. I suspect there is more unrecognized low hanging fruit to speed it up.

???
Look at the profile again, there is nothing left but a smarter template instantiation (it dominates 65% when accounting for self+child time).
Last time I squeezed 1% out of the compiler I had to rewrite StringTable.

3. dmd for Windows is compiled by the same backend as dmd has, so there shouldn't be a speed difference there.

That's true, the slowdown would only hit half of our user base.

4. I want to unwind the changes that resulted in the large dmd slowdowns that recently appeared and find other ways.

That only affected single file compilation, so it doesn't help.
Also we can't undo this w/o reintroducing bugs.

5. Having the source code in D offers possibilities for optimization that are not so practical in C++ source.

That's a vague hope at best. In fact we'll first have to deal with small slowdowns caused by D, e.g. unnecessary initialization.


If you want to compensate the slowdown by optimizing the compiler we should first try to improve our template instantiation, then do the switch.
https://trello.com/c/L0nV131G/17-investigate-fix-compiler-slowdown
https://github.com/D-Programming-Language/dmd/pull/4780#issuecomment-124087604

Let me try if I can get ddmd numbers for ldc, that seems like a more feasible approach to me.