<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 10 June 2013 11:25, Martin Nowak <span dir="ltr"><<a href="mailto:code@dawg.eu" target="_blank">code@dawg.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On 06/10/2013 08:29 AM, Don Clugston wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yeah, my point was that for N tests, we get O(N^^2) templates instantiated.<br>
</blockquote></div>
How is that?</blockquote><div><br></div><div>Just correlation, not causality! The million-ish instantations only comes from a thousand tests.<br></div><div class="im"> <br>
> Wow! (How many of those are unique, rather than reusing an existing instantiation?)<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The number of instances is also a huge performance issue when searching for existing instantiations, because search is done linear and comparing two TemplateInstance uses the costly arrayObjectMatch on the template arguments. So in average instantiating the same template N times uses O(N^^2 / 2) comparisons.<br>

I once improved that by computing the mangling before the search and using it as a key.<br>
That brought down the compilation time of std.range with unittests from 10 to 2 seconds.<br>
There is at least one blocker though <a href="http://d.puremagic.com/issues/show_bug.cgi?id=7469" target="_blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id=7469</a>.<br></blockquote><div><br></div><div>Interesting. This is looking like an area where an order of magnitude improvement in both memory consumption and speed is possible...<br>
</div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Error: out of memory<div class="im"><br>
> This has happened many times before, and we dealt with it by reducing the number of modules we compiled into each object file. We once had 30 modules per obj file. Then fifteen. Then five. But now we're at one, that workaround can no longer be used.<br>

<br></div>
I ran into some issue when preparing the phobos unittests for shared libraries.<br>
If you compile the whole library at once with unittests enabled it consumes ~6GB of RAM.<br>
In order to find a good partition I took up the idea of clustering ( <a href="http://d.puremagic.com/issues/show_bug.cgi?id=9673#c2" target="_blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id=9673#c2</a>, <a href="https://gist.github.com/dawgfoto/5747405" target="_blank">https://gist.github.com/<u></u>dawgfoto/5747405</a>). Well, at least clustering by imports did only find a few useful partitions because almost every module ends up importing std.range or std.algorithm. It might be interesting to do some analysis for the template instances used in each module.</blockquote>
<div><br></div><div>I think the biggest problem is traits.d.  It contains ultra-lightweight templates that are used everywhere and have no dependencies, things like Unqual!(). But it imports <br>std.typetuple (which is OK, it only imports std.traits), <br>
std.typecons. (which imports std.array, std.conv, std.exception, std.format, std.string, std.range)<br>std.algorithm (which imports std.array, std.ascii, std.container, std.conv, std.exception, std.functional, std.math, std.random, std.range, std.string,<br>
    std.uni, std.utf)<br></div><div>... ie, basically all of Phobos<br><br></div>If we could split those things out into a 'leaf' module, probably most of the import graph complexity would disappear. I'm sure most of the cyclic imports are false dependencies.<br>
<div class="h5"> <br></div></div></div></div>