Posted by
Adam Heath-2 on
Jun 09, 2010; 10:44pm
URL: http://ofbiz.116.s1.nabble.com/EntityCondition-factory-objects-tp2249286p2249654.html
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.
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.
>>>>
>>
>>