At least I'm willing to admit it... :) -David
On Jun 10, 2010, at 2:18 AM, Adrian Crum wrote: > 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 <d...@me.com> wrote: > >> From: David E Jones <d...@me.com> >> Subject: Re: Discussion: When To Use Javolution (was: EntityCondition >> factory objects) >> To: dev@ofbiz.apache.org >> 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 <adrian.c...@yahoo.com> >> 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 <scott.g...@hotwaxmedia.com> >>>> wrote: >>>> >>>>> From: Scott Gray <scott.g...@hotwaxmedia.com> >>>>> Subject: Re: Discussion: When To Use >> Javolution (was: >>>> EntityCondition factory objects) >>>>> To: dev@ofbiz.apache.org >>>>> 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 <adrian.c...@yahoo.com> >>>>> wrote: >>>>>>> --- On Wed, 6/9/10, David E Jones >>>>>>> <d...@me.com> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> > > >
