[xmlp] the recent garbage collector performance improvements

Robert Jacques sandford at jhu.edu
Wed Feb 1 20:38:51 PST 2012

On Wed, 01 Feb 2012 18:40:20 -0600, dsimcha <dsimcha at yahoo.com> wrote:
> On Wednesday, 1 February 2012 at 23:43:24 UTC, H. S. Teoh wrote:
>> Out of curiosity, is there a way to optimize for the "many small
>> allocations" case? E.g., if a function allocates, as temporary
>> storage,
>> a tree with a large number of nodes, which becomes garbage when
>> it
>> returns. Perhaps a way to sweep the entire space used by the
>> tree in one
>> go?
>> Not sure if such a thing is possible.
>> T
> My RegionAllocator is probably the best thing for this if the
> lifetime is deterministic as you describe.  I rewrote the Tree1
> benchmark using RegionAllocator a while back just for comparison.
>   D Tree1 + RegionAllocator had comparable speed to a Java version
> of Tree1 run under HotSpot.  (About 6 seconds on my box vs. in
> the low 30s for Tree1 with the 2.058 GC.)
> If all the objects are going to die at the same time but not at a
> deterministic time, you could just allocate a big block from the
> GC and place class instances in it using emplace().

An XML parser would probably want some kind of stack segment growth schedule, which, IIRC isn't supported by RegionAllocator.

More information about the Digitalmars-d mailing list