http://ofbiz.116.s1.nabble.com/EntityCondition-factory-objects-tp2249286p2250677.html
> 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.
Actually, some of those differences are well documented. The performance
> 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.
Remarks like this do little to advance the sharing of information.
I gave a simplified example to demonstrate what I was talking about. I
wasn't trying to appear superior. It's true that "most of this stuff
> 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.
designs. Like I said earlier, some of those performance differences can
chosen based on their design and intended use. I'm not advocating
I look at it like the gas mileage I get with my car. If my mileage
knowledge. I can check the air pressure in my tires to see if they are
under-inflated. I can clean the 50 pounds of clutter out of my trunk. I
can replace a clogged air filter. I don't need to connect my car to
because it's common knowledge that they do. If I do all of the common
> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>