<div dir="ltr">Can't we solve this by exploding the modules into packages and only importing the sub-modules?  This fixes the ball-of-mud problem.<div><br></div><div>If we break up std.algorithm we break up the memory consumption...  although IIRC the huge number of templates comes from exhaustive instantiation in several test cases.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 11, 2013 at 6:01 AM, Walter Bright <span dir="ltr"><<a href="mailto:walter@digitalmars.com" target="_blank">walter@digitalmars.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 6/10/2013 2:25 AM, Martin Nowak wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
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>

</blockquote>
<br></div>
One idea to deal with that is to find a way to order the list, so searching could be binary search time instead of linear.<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
dmd-internals mailing list<br>
<a href="mailto:dmd-internals@puremagic.com" target="_blank">dmd-internals@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/dmd-internals" target="_blank">http://lists.puremagic.com/<u></u>mailman/listinfo/dmd-internals</a><br>
</div></div></blockquote></div><br></div>