More embarrassing microbenchmars for D's GC.

[dsimcha]

== Quote from Sean Kelly (sean at invisibleduck.org)'s article
> dsimcha Wrote:
> > == Quote from Rounin (davidjo at student.matnat.uio.no)'s article
> > > Complicating the code by avoiding associative arrays isn't really an option,
> > > though, as the whole point of writing the program was comparing D to Python in
> > > terms of simplicity.
> >
> > How about using a library defined associative array?  As I've mentioned several
> > times here before, D's current builtin associative array implementation interacts
> > horribly with the GC.  This is true both in terms of speed and memory usage.
> > Neither D's GC nor its AA implementation is that bad per se, but the AA
> > implementation seems to expose all the weaknesses in the GC, such that the result
> > when using large AAs is laughably bad.  I think eventually we need to completely
> > redesign and rewrite it, or at least put a sealed implementation in std.container
> > that's more geared towards huge AAs.
> The precise scanning patch would probably help tremendously here.

Yes, it would but even so, I don't think that a good AA implementation for a GC
like D's should require an allocation on **every single insert**.  This makes AAs
basically unusable in parallel code.