Cool. Reminds me of the controversy over using antiseptic to aid open wound
healing.
Most antiseptics were tested in vitro. In vivo tests results recently show marked differences from
prior in vitro results.
Hmm. Example... say... PVP-I and cadexomer iodine. PVP-I with low concentration actually boosts
bacteria growth in open wounds! High concentrations kill repair cells. Curious how science is so
very very inaccurate, especially in in vitro tests. :) I'm still looking for published results for
the newer cadexomer starch form.
Please don't reply. Totally off-topic. Just thought David crafted a cool explanation of the
science of computing.
Jonathon
David E Jones wrote:
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.
