Karl, That's a good way to look at it. The JDK definitely progresses over time and more standard approaches may very well do as well or better.
If anyone wants to do some profiling to compare some alternatives to current framework code, that would be neat to see and would "seal the deal" as it were. Profiling is how we got into object pooling years ago, and it may be how we get out of object pooling too! -David On Jun 13, 2010, at 11:26 PM, Eilebrecht, Karl (Key-Work) wrote: > Hi, > > I've just read your conversation and I want to add my two cents: > > When I started using Ofbiz I stumbled across the Javolution stuff inside and > was really fascinated > because that time I was interested in object pooling during research for a > chapter of my pattern book. > Javolution seems to be reliable and it is well documented. > I think the main power comes with the contexts concept. > Well, the contexts did not seem to be used in ofbiz that time, or have you > started using > them in the meantime? I did not check the last built - but I don't think so. > Although, not using the context concept of Javolution one may lose some of the > advantages, Javolution still seems to provide clever implementations with a > higher > performance resp. better memory/concurrency behavior than standard JDK > classes under certain circumstances. > Maybe a big point for Javolution. But how long? > > The JDK shows an interesting evolution over the last years. Every new JDK > has not only brought new features but also improvements to existing ones. > With every new JDK you'll receive these improvements (tested by millions of > people) > for free mostly with full backward compatibility. Using a third-party library > any upgrade to the next version needs more attention, more discussion and > more tests > ( community(third party library) <= community(JDK) ;-) ). > Thus I came to the conclusion to not use Javolution for other projects than > Ofbiz > when there is no explicit need to do so. > > So, if you do not expect clear advantages from Javolution (other than "could > be", > "theoretically" or "just a feeling") I would recommend to migrate back from > Javolution classes to > standard JDK classes and - where appropriate - to use java.util.concurrent > classes. > > Regards > Karl > > Karl Eilebrecht > Key-Work Consulting GmbH | Kriegsstr. 100 | 76133 Karlsruhe | Germany | > www.key-work.de > Fon: +49-721-78203-277 | E-Mail: karl.eilebre...@key-work.de | Fax: > +49-721-78203-10 > > Key-Work Consulting GmbH Karlsruhe, HRB 108695, HRG Mannheim > Geschäftsführer: Andreas Stappert, Tobin Wotring > -----Ursprüngliche Nachricht----- > Von: Scott Gray [mailto:scott.g...@hotwaxmedia.com] > Gesendet: Donnerstag, 10. Juni 2010 10:33 > An: dev@ofbiz.apache.org > Betreff: Re: Discussion: When To Use Javolution (was: EntityCondition factory > objects) > > I will admit to thumping my chest and saying "ahhhhhhhh" at the same time. > > But only after you guys mentioned it and only to bring back childhood > memories. Maybe I need some rest. > > Regards > Scott > > On 10/06/2010, at 8:23 PM, David E Jones wrote: > >> >> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> > >
