Well, impossible is a rather strong word, considering that the win32 auto-tester seems to be doing
it's job successfully.
I _do_ consider it a compiler memory management issue. There's no reason that the entirety of
phobos (or pretty much any app) ought to be compilable in one shot. There's approximately 10M of
source for druntime+phobos and some how it can't fit in a couple _gigs_ of ram? And looking at
std.algorithm, that's a mere 342k of source code. Yes, it grows, but 4 orders of magnitude?
As to what to do, how much memory do you have and are you using the snn.lib update that Walter
released a few years ago that fixed the memory allocator in it to not suck so bad?
md5: 9357508e541067ea34056dade4381dd8 dmc/dm/lib/snn.lib
On 6/8/13 11:12 AM, Don Clugston wrote:
With win32, I can no longer run unittests:
------------------
dmd -O -w -d -property -L/co -c -unittest -ofunittest5.obj std\algorithm.d
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.
The idea that we can continue to throw billions of templates and imports into
every Phobos module,
is leading us towards catastrophe.
Sure, you can say, the compiler should improve its memory management. But I
don't think that's
really the problem. If it was better, then compiler might not run out of
memory, but it would run
unusably slowly. I think most people have no idea of just how many templates
the compiler is being
asked to instantiate.
Every import has a cost, and that cost is far from zero.
I'm stuck, and I don't know what to do.
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals