It is actually a pretty big deal, and there are very good reasons it was integrated into OFBiz. In OFBiz we deal with LOTS of temporary objects, especially Maps and Lists, and when doing performance profiling you can see the impact of this in the results (ie lots of time creating objects and allocating memory, lots of work for the garbage collector to do when destroying objects and un-allocating memory). Because of this it makes a big difference to use recycled objects like the Javolution FastMap and FastList, ie calling FastMap.newInstance() to get an object out of the pool of existing FastMap objects rather than calling new HashMap() to create a new HashMap each time.
There are actually lots of performance tricks that OFBiz uses, though most of the work was done before most of the people now involved with OFBiz were around. Early on I spent a few weeks profiling and tweaking over the course of a few months as things were being heavily developed. Our classpath caching, special purpose internal methods in the entity engine, and the use of Javolution for the Fast* objects and for object recycling for often used but short-lived things like the GenericValue object (which is a recycled object) are all results of that effort.
For other things like get and put operations on a FastMap versus a HashMap... I wouldn't expect a whole lot of difference. It may be that FastMap does a better job of managing large and scattered hash arrays or something but there is really only so much you can do with that as those algorithms have been around for a LONG time and have been thoroughly reviewed and refined by lots of people. To really get an understanding of this would require a bit of research, but it's all very standard computer science stuff, so the material is readily available and very accessible if you get a decent book or whatever. It is nice stuff to know about because these basic data structures and algorithms are what everything is based on in modern software and understanding them makes it way easier to understand performance impact and interpret the results of profiling, as well as understand higher level algorithms and data structures like those used in relational databases and such.
Knowing all of that stuff is of course not a substitution for using a profiling tool, and in fact those who really understand the stuff know all the more how important it is to use profiling tools. The nature of the software is that it is very complex, and even if you know it all it's hard to remember and grok the importance of certain pieces sometimes. In other words it's deterministic, but complex. The most experienced people will know that they might be able to guess really well and understand really well the general things that might impact performance, but until you do profiling and tweaking to see a performance difference they are only guesses and guesses aren't proofs, and aren't enough if you're trying to be careful and make a real difference in something.
In short, doing profiling is great and extremely valuable, as is understanding the underlying data structures and algorithms. However, neither of them along is sufficient to really understand and describe why something is performing a certain way or make a difference in how it performs.
-David On Dec 14, 2007, at 1:28 PM, Jacques Le Roux wrote:
Sumit, Adrian, All, I had a cursory look at it. In abstract, yes this seems to be right Though those lines you took from Google are 4 years old http://www.javalobby.org/java/forums/t9377.html?start=15#reply20Anyway it seems to be right, here the answer from Javolution Creator (JM Dautelle) The best analogy between FastMap and HashMap would be buying versus renting. With FastMap you pay upfront but you are done with it. With HashMap you pay each time you "put" a new entry (not only when you allocate but also later with the GC interests...). Obviously if you intend to sell your house three months later it does not make sense to buy it.Also interesting is JM Dautelle's this note found at http://javolution.org/doc/benchmark.htmlAlthough it looks nice, I see that some of your collection classes are not always faster than their Java 6 counterparts.<<Some classes are faster, others are slower (for example ArrayList.get(int) is faster with the -server option, slower without it). Overall, there is no significative difference in average execution time. The main advantage of Javolution collections is that they are time-deterministic (the maximum execution time is very close to the minimum execution time) and they are RTSJ-Safe. They have some additional characteristics such as thread-safe without synchronization, support for custom key/value comparators, direct record iterations (faster than iterators), recyclable, reduced impact on GC (fragmentation or large arrays allocations), support for custom entry implementation (FastMap) or custom node implementation (FastList), etc.>>See also http://noctarius.l2castell.org/download/benchmark_trove_javolution_java.pdfMaybe knowning the real reason(s?) it was integrated in OFBiz would be cool, does not look like a big deal tough, am'I wrong ?Jacques De : "Adrian Crum" <[EMAIL PROTECTED]>I just spent some time running performance tests on FastMaps and HashMaps. Calling the get methods showed no speed difference. The Javalution classes seem to have a speed advantage in building Maps and Lists. They claim their FastSet.removeLast method is faster than the Java library. So, there isa speed advantage in certain scenarios, but not in all cases. -Adrian Sumit Pandit wrote:*i have a question please make me correct if i am wrong :-* if we compare FastMap Vs HashMap, *FastMap is faster than HashMap so long as the map is long lived andrelatively predictable in size. If you try to use it as a short- lived general replacement for HashMap it may very well kill your performance.*I found these lines some where in Google. so does it mean that we should use HashMap for local variables ?Also please explain me the performance issue if we use HashMap rather thenFastMap. Thanks for suggestion.
smime.p7s
Description: S/MIME cryptographic signature