Damn it, why is that I always miss key words in sentences?!? Always has to be the one that if missing, completely reverses the message I intended to convey:
> 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. I'm _NOT_ disagreeing with what you're saying... Regards Scott On 10/06/2010, at 6:56 PM, Scott Gray wrote: > 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 >>> >>> >>> >>> >>> >> >> >> >
smime.p7s
Description: S/MIME cryptographic signature
