--- 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
