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