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.
My opinion is that javolution usage should start to be phased out.
-Adrian
On 6/9/2010 1:28 PM, Adam Heath wrote:
Adrian Crum wrote:
"Public service announcement: Object pooling is now a serious
performance loss for all but the most heavyweight of objects, and even
then it is tricky to get right without introducing concurrency
bottlenecks."
http://www.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends
What's cute about this, is that that article is from *before* the
factory stuff was added to conditions.
-Adrian
On 6/9/2010 11:19 AM, Adam Heath wrote:
Why does EntityCondition create objects from a factory? This means
that any condition that needs to be created will end up storing the
object into the global heap, with all the requisite locks and
contention that occur from that. If a new object was just created,
however, java1.6 has the ability to allocate it on the stack, when
then means freeing said object is much more efficient.
I'm suggesting that the global factories for conditions be removed,
but the actual factory methods themselves should remain.
