--- On Thu, 6/10/10, David E Jones <d...@me.com> wrote: > 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 <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 > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > >
