More embarrassing microbenchmars for D's GC.

[dsimcha]

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

My RandAA can be several times faster than the builtin AA when dealing with huge
arrays (purely due to memory management overhead), and some tweaking by others in
the community has produced an even faster version.  Furthermore, it doesn't create
tons of heap fragmentation and false pointers for the GC.  I've solved out of
memory errors with the builtin AA in some small projects just by swapping in
RandAA for it.  (See http://dsource.org/projects/aa)