FastMap Vs HashMap,

[Sumit Pandit-4]

*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

[Adrian Crum]

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.
>

[Jacques Le Roux]

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" <[hidden email]>

> 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.
> >
>

[David E Jones]

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" <[hidden email]>
>> 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.
>>>
>>
>

[Jacques Le Roux]

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" <[hidden email]>

> 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" <[hidden email]>
> >> 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-4]

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 <[hidden email]>
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" <[hidden email]>
> > 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" <[hidden email]>
> > >> 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

[David E Jones]

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 Pandit
>
> On Dec 15, 2007 6:55 AM, Jacques Le Roux  
> <[hidden email]> 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" <[hidden email]>
> > 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" <[hidden email]>
> > >> 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

[jonwimp]

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" <[hidden email]>
>>> 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.
>>>>
>>>
>>
>

[Jacques Le Roux]

Not sure it's really a science, look more like a collection of recipes to me ;o) With a real science you have preditable results,
not with computers (even if in most cases "it works"). There are some good theories but what's really new since Turing machine
(joking) ?

Did you know that for each MS developers there are more or less 5 to 10 testers ? Nasa is at least 100 for a developper (not sure
about this numbers, just hears about them) !

Jacques

PS : seems we need some fun...

De : "Jonathon -- Improov" <[hidden email]>

> 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" <[hidden email]>
> >>> 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.
> >>>>
> >>>
> >>
> >
>