I backed it up in an indirect way by
mentioning the need to understand the Javolution library and
its intended use. Go here to find out more:
http://javolution.org/
To summarize: Javolution was intended to be used in
real-time systems where timing is critical. The library's
goal is timing that is *consistent*, not necessarily fast.
OFBiz is not a real-time application - it isn't being used
to control robots or Mars rovers or anything timing-critical
like that.
You have to spend time on the Javolution site and poke
around in their code a bit to understand the
advantages/disadvantages. Adam has mentioned some of them in
this thread and in previous threads.
FastList implements a doubly-linked list. The list nodes
are kept in an object pool. ArrayList wraps an array. If you
think about it, the advantages/disadvantages will start to
become evident. FastList will perform additions and removals
more consistently than ArrayList because the change involves
adding/removing a node. ArrayList resizes/copies the array
it wraps, so the timing depends on the size of the array. A
doubly-linked list will take more memory than ArrayList
because the list elements are wrapped with nodes. An
ArrayList will take more memory than the array it wraps
because it contains additional bookkeeping data.
-Adrian
--- On Wed, 6/9/10, Scott Gray<[email protected]>
wrote:
From: Scott Gray<[email protected]>
Subject: Re: Discussion: When To Use Javolution (was:
EntityCondition factory objects)
To: [email protected]
Date: Wednesday, June 9, 2010, 11:56 PM
Interesting post but what I'm not
hearing is any mention of specific downsides to using
javolution in place of the util classes even when the
use
may not be taking advantage of any specific
javolution
features.
You mention this:
There is no performance benefit to using FastList
in
this scenario. An ArrayList will use less memory and
will
perform faster than FastList - if its size is
initialized to
the correct value. Better yet, if you know the number
of
objects in advance, then just create an array.
But you provide no evidence to back the statement
up.
And a FastList can also be given an initial size.
I'm disagreeing with what you're saying because I
really
don't know much about it, but your post doesn't really
do
much to increase my knowledge or give me any reason
to
follow your advice.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 10/06/2010, at 6:25 PM, Adrian Crum wrote:
I'm continuing this discussion with a new
subject
since the thread is starting to diverge from the
original
subject.
A lot of the current code uses Javolution classes
in
many places for one common reason - copy-and-paste
development. If you don't understand the Javolution
library
and its intended use and actual benefits then it's
hard to
know when the classes should be used and when there
might be
better alternatives.
When I see class names like FastList and FastMap,
I
assume using them will speed up code. Indeed, some JRE
class
methods will execute faster using Javolution instead
of JRE
classes, and those methods are well documented on the
Javolution website. If a bit of code doesn't use any
of
those methods, then there will be no benefit to using
Javolution.
Adam and I discussed earlier the use of object
pools.
Object pools used to improve performance because they
helped
cut down on garbage collection. Sun/Oracle recommends
getting rid of object pools when using the newer
versions of
Java because the newer versions have improved garbage
collectors.
If you do a Google search for "java performance
improvement" you'll get a lot of links to a lot of
articles.
From my experience a lot of those ideas are based on
some
special knowledge of how the JVM works and they "game
the
system" to improve performance. As a result, some of
those
optimizations depend on the JVM version and the
platform it
runs on.
My preference is to use efficient algorithms and
well
structured code, and leave the performance
optimizations to
the JVM. I can give an example that will be obvious
to
everyone:
Let's say a section of code builds a List of
objects
and then iterates over the List. Once the List is
created,
its contents don't change - there are no additions,
removals, inserts, etc. In addition, this List will be
a
member of an object that is kept in a cache.
There is no performance benefit to using FastList
in
this scenario. An ArrayList will use less memory and
will
perform faster than FastList - if its size is
initialized to
the correct value. Better yet, if you know the number
of
objects in advance, then just create an array.
If an ArrayList is used, you can call the
trimToSize
method after the List is filled to reduce the memory
it
uses. Better yet, convert it to an array to reduce
memory
use even more. A cached object that contains an array
instead of FastList will take less memory and perform
better.
So, the main idea is to think about how the
collection
is being used and then choose the best class for it.
Don't
assume a Javolution class will always perform better.
By the way, I'm not pointing any fingers or
talking
down to anyone here. I've done the copy-and-paste
development myself. It's only recently that I started
to
scrutinize my choice of classes.
-Adrian
--- On Wed, 6/9/10, Adrian Crum<[email protected]>
wrote:
--- On Wed, 6/9/10, David E Jones
<[email protected]>
wrote:
On Jun 9, 2010, at 4:56 PM, Adrian Crum
wrote:
On 6/9/2010 3:44 PM, Adam Heath
wrote:
Adrian Crum wrote:
I remember when Javolution
was
first
brought
into the project. The
reason for adding it was
better
performance. I
was new to the project at
the time, so I just assumed
that
was
true.
Since then I have read many
books
and
articles
on Java, and now I'm not
sure that Javolution is
appropriate for
this
project.
I've also had doubts about
FastMap(javolution). It doesn't
implement
ConcurrentMap; the putIfAbsent
method
it
*does*
implement is not
completely defined.
FastSet/FastMap don't have a
defined
order.
It appears to be linked,
when no Comparator is used, but
that
is not
well
defined.
javolution itself is supposed to
be
defined
as
being more consistent
in memory usage and
performance.
The
library
says these are useful
when the target platform is an
embedded
environment. However, ofbiz
is not really an embedded-type
application.
The extra overhead that
javolution uses for maintain
memory
block
areas
makes it very hard for
the jvm to do the new fancy
escape
analysis.
Lots of places in ofbiz use
FastMap/List/Set. They are not useful,
however, in places that only get
populated
at
startup, and never ever
changed thereafter. I've
started
fixing
some
of these use cases as I
spot them.
I've used arrays instead of Lists in
similar
cases. We
really should have a discussion about
this.
Using
Javolution
by default in a shotgun attempt to
improve
performance
is
not a good strategy, in my opinion.
I agree. If I understand correctly are
you
saying that
the
move away from javolution will NOT be
done as
a
shotgun
attempt to improve performance?
Correct. Any changes that are made should be
for a
good
reason.
-Adrian
