http://ofbiz.116.s1.nabble.com/EntityCondition-factory-objects-tp2249286p2250031.html
Oops, I forgot to explain iteration differences. Iterating over an array is faster than traversing a doubly-linked list.
> 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 <
[hidden email]>
> wrote:
>
> > From: Scott Gray <
[hidden email]>
> > Subject: Re: Discussion: When To Use Javolution (was:
> EntityCondition factory objects)
> > To:
[hidden email]
> > 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 <
[hidden email]>
> > wrote:
> > >> --- On Wed, 6/9/10, David E Jones
> > >> <
[hidden email]>
> > >> 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
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
>
>
>
>