Can't we solve this by exploding the modules into packages and only importing the sub-modules? This fixes the ball-of-mud problem.
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. On Tue, Jun 11, 2013 at 6:01 AM, Walter Bright <[email protected]>wrote: > > On 6/10/2013 2:25 AM, Martin Nowak wrote: > >> >> >> 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. >> > > 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. > > ______________________________**_________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/**mailman/listinfo/dmd-internals<http://lists.puremagic.com/mailman/listinfo/dmd-internals> >
_______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
