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 <[email protected]> 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 <[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 > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > >
