http://ofbiz.116.s1.nabble.com/EntityCondition-factory-objects-tp2249286p2250053.html
> On Jun 10, 2010, at 1:42 AM, Adrian Crum 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.
>
> That's hardly the only goal for Javolution, and certainly
> not the reason it is used in OFBiz. The main reasons were
> object pooling/reuse and faster Map (and sometimes List)
> performance for those that are pretty dynamic during their
> life (even if it is short).
>
> > 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.
>
> There's really quite a bit more to it than that, ie lots of
> reasons to choose a linked list, doubly linked list, or an
> array (in Java either literal or array list).
True. I was explaining the reasoning behind the choice in my example, I was not suggesting that choice should be applied to all of OFBiz.
> However, for most of OFBiz chances are it won't make much
> of a difference in memory usage or execution time. The fact
> is these things do get complicated and it's nice to know
> about different options and what might work better in a
> certain circumstance, but just because in theory it might
> use less memory or execute faster doesn't mean that it
> actually will, or it might make a difference but not a
> measurable one by even a performance testing tool and
> certainly not something that even on a larger scale a user
> would notice because other factors dominate so much that
> such changes are little more than background noise.
>
> That's why I brought up profiling. Again, for most of OFBiz
> (especially business logic) what it used won't make any
> significant difference. There may be a few places in the
> framework where things could be improved, but searching
> through the code for these trying to find patterns that
> _might_ perform worse than an alternative may make no change
> at all, or may even make things worse. Profiling will help
> you know if it really improved things, and will also help
> you find actual performance problems (memory use and
> execution time) instead of poking around in the dark.
>
> Once a performance problem is found, then you can start
> experimenting with changes that will improve things, and
> then some of these ideas might be helpful. Until then, it's
> great to share information but IMO it is not actionable at
> all (or wise to act on any way with profiling, unless you
> have time to kill and aren't concerned about the risk of
> doing more harm than good).
>
> -David
>
>
> > --- 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>