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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >
smime.p7s
Description: S/MIME cryptographic signature
