Michael Rynn <> changed:

           What    |Removed                     |Added
                 CC|                            |

--- Comment #4 from Michael Rynn <> 2010-04-17 04:50:13 PDT 
See enhancement 4098.
I have experimented with a NodeHeap for the AA, that allocates Nodes in much
bigger blocks, and this does speed by up a considerable amount the insertion
and cleanup times. The NodeHeap idea is a single sized block dedicated heap
manager created for each AA instance.

No advantage at all for lookup times.

The disadvantage is that Nodes released by a remove, are not returned to the GC
pool until the entire block of Nodes has been removed. Of course when it does
get freed, its in a big blocks at once. Also when allocating Nodes one after
the other, I suppose a smart memory heap might be carving up much bigger blocks
anyway, with various Pools for different object sizes.  

Having a manual AA.clear helps the GC as well. 

Even so, having a node heap and using for the first time, the system must get a
new big bunch of memory, and maybe that will always take some time.

Its not in the current 4098 set (which is a lot to swallow already), but I it
could be an optional run time extra parameter to the HashMap/HashSet setup
wrapper. It uses lots of really small nodes.

The AA management object would then have a non-null heap manager object, to
allocate and free blocks from a dedicated instance pool (Just like the Tango
HashMap, which does exactly this).

I have already proposed to add some more fields to the hash map management
object, and one more non-default runtime option (only available from HashMap
template wrapper) will hopefully not be a heap of trouble.

If it was an option, would people use it wisely?

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to