I really don't have a recommended profiling tool. Over the course of years these tend to come and go, and historically most of them have been commercial and created and sold by smaller companies. There are some open source ones out there these days, but I haven't really used any of them enough to recommend for or against them (still, that's where I'd start right now if I needed to do some profiling).
It's been a while since a thorough performance review has been done on OFBiz, a few years probably, but one hasn't really been needed because few fundamental framework things have changed. It would still be nice to do, but doing so with something like OFBiz is easily a one man-week sort of effort.
-David On Dec 14, 2007, at 11:27 PM, Sumit Pandit wrote:
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 PanditOn 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 somecirconstances.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
smime.p7s
Description: S/MIME cryptographic signature
