On 06/10/2013 08:29 AM, Don Clugston wrote:

Yeah, my point was that for N tests, we get O(N^^2) templates instantiated.

How is that?

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.
I once improved that by computing the mangling before the search and using it as a key.
That brought down the compilation time of std.range with unittests from 10 to 2 seconds.
There is at least one blocker though http://d.puremagic.com/issues/show_bug.cgi?id=7469.

> Error: out of memory

> 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.

I ran into some issue when preparing the phobos unittests for shared libraries.
If you compile the whole library at once with unittests enabled it consumes ~6GB of RAM.
In order to find a good partition I took up the idea of clustering ( http://d.puremagic.com/issues/show_bug.cgi?id=9673#c2, https://gist.github.com/dawgfoto/5747405). 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.