http://d.puremagic.com/issues/show_bug.cgi?id=2504
Michael Rynn <y0uf00...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |y0uf00...@gmail.com --- Comment #4 from Michael Rynn <y0uf00...@gmail.com> 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: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------