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. -Adrian --- On Thu, 6/10/10, David E Jones <[email protected]> wrote: > From: David E Jones <[email protected]> > Subject: Re: Discussion: When To Use Javolution (was: EntityCondition factory > objects) > To: [email protected] > 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 <[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 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > >> > > > > > > > >
