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 <walter@digitalmars.com> 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
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals