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? If so, excellent! I can't wait to see the performance test code and the before and after comparisons for each change! -David
