<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 August 2015 at 08:40, Martin Nowak via dmd-internals <span dir="ltr"><<a href="mailto:dmd-internals@puremagic.com" target="_blank">dmd-internals@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wednesday, 12 August 2015 at 00:44:19 UTC, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
30% is a problem, but not a disaster. Some mitigating factors:<br>
<br>
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.<br>
</blockquote>
<br></span>
Yes, but it's seems a bit unrealistic to rewrite template instantiation and make a ddmd switch in one release.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></span>
???<br>
Look at the profile again, there is nothing left but a smarter template instantiation (it dominates 65% when accounting for self+child time).<br>
Last time I squeezed 1% out of the compiler I had to rewrite StringTable.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. dmd for Windows is compiled by the same backend as dmd has, so there shouldn't be a speed difference there.<br>
</blockquote>
<br></span>
That's true, the slowdown would only hit half of our user base.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. I want to unwind the changes that resulted in the large dmd slowdowns that recently appeared and find other ways.<br>
</blockquote>
<br></span>
That only affected single file compilation, so it doesn't help.<br>
Also we can't undo this w/o reintroducing bugs.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
5. Having the source code in D offers possibilities for optimization that are not so practical in C++ source.<br>
</blockquote>
<br></span>
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.<br>
<br>
<br>
If you want to compensate the slowdown by optimizing the compiler we should first try to improve our template instantiation, then do the switch.<br>
<a href="https://trello.com/c/L0nV131G/17-investigate-fix-compiler-slowdown" rel="noreferrer" target="_blank">https://trello.com/c/L0nV131G/17-investigate-fix-compiler-slowdown</a><br>
<a href="https://github.com/D-Programming-Language/dmd/pull/4780#issuecomment-124087604" rel="noreferrer" target="_blank">https://github.com/D-Programming-Language/dmd/pull/4780#issuecomment-124087604</a><br>
<br>
Let me try if I can get ddmd numbers for ldc, that seems like a more feasible approach to me.</blockquote><div><br></div><div>For the sake of completeness, I can backport cppmangle from 2.067 down to gdc to allow you to test that also, I have already verified that it is all that's needed to build ddmd (with a couple of small omissions or changes) and the resultant compile passes the D2 testsuite.<br><br></div><div>Regards<br></div><div>Iain<br></div></div><br></div></div>