[dmd-internals] 3rd Biweekly Sprint Planning

[Martin Nowak via dmd-internals]

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.