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.
Generally true; but 1000 milliseconds = 1 sec. -- i.e., it all depends how "hot" the code segment that you are optimizing is.
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.
Optimized solutions with nice interfaces are the best of both worlds. Flat3Map just looks like a Map from the outside.
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.
Not always. Even with recent JDKs (which lots of users still don't get to use), heavily loaded web apps can run into problems if they create too many complex objects per request.
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.
I agree with you here. I can't envision a scenario where I would use this class. A "lightweight HashMap" for things like JNDI or controller lookups might be useful; but not with such a small limit on the number of entries. The natural thing to think about would be a configurable "breach point"; but I doubt that this could be implemented even as efficiently as what the HashMap implementation already provides.
An interesting question is for what value of n does a FlatnMap give worse performance than a HashMap?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
