http://ofbiz.116.s1.nabble.com/EntityCondition-factory-objects-tp2249286p2250069.html
My point was made since the beginning of the original thread. Javolution might not be the best choice in all situations. Let's discuss that.
As far as I can tell, no one here is thumping their chest. Adam asked a legitimate question. I pointed to an informative article related to his question. We discussed the premise of that article. I thought it would be helpful for the community to discuss it further. Scott asked for more information and I offered it. If any chest thumping was done, it was in your last reply.
> From: David E Jones <
[hidden email]>
> Subject: Re: Discussion: When To Use Javolution (was: EntityCondition factory objects)
> To:
[hidden email]
> Date: Thursday, June 10, 2010, 1:08 AM
>
> I'm sure there are good references around with a more
> complete list of differences. Be careful about pushing some
> differences and leaving out others, especially when bias is
> involved (ie arrays are better than linked lists). It may be
> that in some circumstances iterating is faster, but if so
> probably not by much (ie the difference between following a
> pointer versus incrementing an index).
>
> There are some things that linked lists do far better (like
> sorting, and most modifications actually), and if not
> intentionally optimized they can actually require more
> memory instead of less for smaller lists.
>
> To Scott's point... what (again) was the point of all of
> this? I guess it's always fun to thump one's chest and
> demonstrate knowledge of the concepts behind basic data
> structures, but most of this stuff fits into freshman
> computer science material, so even that isn't so much fun s
> not many people will be impressed.
>
> To your point Adrian, this stuff is definitely an issue,
> but unless you're looking at a specific piece of code and
> you actually profile to test alternatives it's really quite
> difficult to guess at what is better.
>
> That's part of the fun of profiling, the moment you find
> you were wrong is roughly the same moment when you find out
> what is right, even if it's often not what you expected.
> There are very few activities in life where those two events
> occur so close together... so it makes it kind of fun and
> only occasionally frustrating instead of the other way
> around... ;)
>
> -David
>
>
> On Jun 10, 2010, at 1:49 AM, Adrian Crum wrote:
>
> > Oops, I forgot to explain iteration differences.
> Iterating over an array is faster than traversing a
> doubly-linked list.
> >
> > -Adrian
> >
> > --- On Thu, 6/10/10, Adrian Crum <
[hidden email]>
> wrote:
> >> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>