Posted by
Adrian Crum on
Jun 09, 2010; 10:56pm
URL: http://ofbiz.116.s1.nabble.com/EntityCondition-factory-objects-tp2249286p2249664.html
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.
>>>>>
>>>
>>>
>
>