Thanks a lot David to have taken the time to clearly explain. I'm sure this will be helpful for a lot of persons in some circonstances.
BTW, would you recommend a specific profiler tool ? I did not use one since I use Java, I should say since I use OFBiz... Jacques De : "David E Jones" <[EMAIL PROTECTED]> > 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#reply20 > > > > Anyway 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.html > >> Although 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.pdf > > > > Maybe 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 is > >> a 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 and > >>> relatively 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 then > >>> FastMap. > >>> > >>> Thanks for suggestion. > >>> > >> > > > >
