[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