commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <>
Subject Re: [collections] Flat3Map, faster than HashMap
Date Mon, 03 Nov 2003 00:52:29 GMT
Performance is always a strange issue.

When you say that Flat3Map is faster than HashMap for <= 3 gets/puts, I 
would think that you're talking about milliseconds.  And, if an 
application has a performance problem, I would suspect that it isn't 
coming from wasted milliseconds caused by small HashMaps.

It's a proven fact that less object creation equals better performance. 
  My concern is always the cost required to obtain this situation.  I'll 
always prefer a nice clean object oriented solution over one that is 
tweaked for performance.  I'll never avoid using a complex type or 
creating an object just because it will hurt performance.  Whether this 
preference is practical in the real world, I'm not sure.

My point is, I'd never see myself using a Flat3Map to improve my apps 
performance, mainly because any performance problems that exist are 
coming from somewhere else.  I'm not sure if there is a valid problem 
for which Flat3Map is a solution.

Question: Did you try testing HashMap with different values for 
initialCapacity and loadFactor?

Any other thoughts?

Stephen Colebourne wrote:
> Well I think I've achieved a neat little class in Flat3Map, but I guess
> others should decide that. (Its checked in, but if people don't like it I'll
> remove it or rename it or otherwise modify it)
> Flat3Map is a Map implementation that is optimised for size 3 and less. It
> stores data in ordinary fields and does not create an array, map entry or
> other complex object until size 3 is breached.
> Once size 4 is reached, a HashMap is created and the Flat3Map behaves as per
> a decorated HashMap.
> Performance wise -
> - Gets at size 3 or less are about 0-10% faster than HashMap.
> - Puts at size 3 or less are over 4 times faster than HashMap.
> - Performance 5% slower than HashMap once size 3 exceeded once.
> The gains on put are probably down to object creation and therefore garbage
> collection. The new MapIterator should be used to get the maximum advantage,
> as it doesn't create MapEntry objects. The performance test class is also
> checked in so you can try it out (you have to play with the comments in the
> loop).
> I also suspect, but can't think how to prove, that Fast3Map will be easier
> for the garbage collector to dispose of as it contains no arrays or complex
> types to hunt through for dependencies. Any ideas on how to test this?
> Opinions? And should there be a Flat1Map, Flat5Map etc. And what about a
> Flat3List??
> Stephen

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message