From: "__matthewHawthorne" <[EMAIL PROTECTED]> > When you say that Flat3Map is faster than HashMap for <= 3 gets/puts, er <= size 3. You can get/put as often as you like, without exceeding size 3.
> 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. Its this that the class targets more. Lots of small object creation and loss is very expensive. > 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. Well of course the point here is that as far as the API user is concerned there is no change - you just use a Map interface. Do you need to care how it is implemented? > 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. At my work we have large complex object models that can cope with large amounts of data. But in probability, most of the time the lists/maps will be small. This class adresses those cases. > Question: Did you try testing HashMap with different values for > initialCapacity and loadFactor? Actually I just did some more tests: Create new Flat3Map() vs create new HashMap() 2910 vs 4060 Create new Flat3Map() put 3 mappings vs create new HashMap() put 3 mappings 4170 vs 8120 Memory usage Size 0: 56 bytes vs 120 bytes Size 1: 56 bytes vs 144 bytes Size 2: 56 bytes vs 168 bytes Size 3: 56 bytes vs 192 bytes Size 4: 272 bytes vs 216 bytes Size 5: 296 bytes vs 240 bytes Object creation on construction: None vs Entry[16] Stephen > > 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]
