Thanks Adrian, Jacques and David for your valuable thoughts. David I admire your explanation power. Great Clarification. Also as Jacques says please recommend a specific profiler tool if possible.
thanks again. Sumit Pandit On Dec 15, 2007 6:55 AM, Jacques Le Roux <[EMAIL PROTECTED]> wrote: > 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. > > >>> > > >> > > > > > > > > > -- Sumit Pandit
