Re: Discussion: When To Use Javolution (was: EntityCondition factory objects)
Posted by Scott Gray-2 on Jun 10, 2010; 6:56am
URL: http://ofbiz.116.s1.nabble.com/EntityCondition-factory-objects-tp2249286p2249982.html
Interesting post but what I'm not hearing is any mention of specific downsides to using javolution in place of the util classes even when the use may not be taking advantage of any specific javolution features.
You mention this:
> There is no performance benefit to using FastList in this scenario. An ArrayList will use less memory and will perform faster than FastList - if its size is initialized to the correct value. Better yet, if you know the number of objects in advance, then just create an array.
But you provide no evidence to back the statement up. And a FastList can also be given an initial size.
I'm disagreeing with what you're saying because I really don't know much about it, but your post doesn't really do much to increase my knowledge or give me any reason to follow your advice.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 10/06/2010, at 6:25 PM, Adrian Crum wrote:
> I'm continuing this discussion with a new subject since the thread is starting to diverge from the original subject.
>
> A lot of the current code uses Javolution classes in many places for one common reason - copy-and-paste development. If you don't understand the Javolution library and its intended use and actual benefits then it's hard to know when the classes should be used and when there might be better alternatives.
>
> When I see class names like FastList and FastMap, I assume using them will speed up code. Indeed, some JRE class methods will execute faster using Javolution instead of JRE classes, and those methods are well documented on the Javolution website. If a bit of code doesn't use any of those methods, then there will be no benefit to using Javolution.
>
> Adam and I discussed earlier the use of object pools. Object pools used to improve performance because they helped cut down on garbage collection. Sun/Oracle recommends getting rid of object pools when using the newer versions of Java because the newer versions have improved garbage collectors.
>
> If you do a Google search for "java performance improvement" you'll get a lot of links to a lot of articles. From my experience a lot of those ideas are based on some special knowledge of how the JVM works and they "game the system" to improve performance. As a result, some of those optimizations depend on the JVM version and the platform it runs on.
>
> My preference is to use efficient algorithms and well structured code, and leave the performance optimizations to the JVM. I can give an example that will be obvious to everyone:
>
> Let's say a section of code builds a List of objects and then iterates over the List. Once the List is created, its contents don't change - there are no additions, removals, inserts, etc. In addition, this List will be a member of an object that is kept in a cache.
>
> There is no performance benefit to using FastList in this scenario. An ArrayList will use less memory and will perform faster than FastList - if its size is initialized to the correct value. Better yet, if you know the number of objects in advance, then just create an array.
>
> If an ArrayList is used, you can call the trimToSize method after the List is filled to reduce the memory it uses. Better yet, convert it to an array to reduce memory use even more. A cached object that contains an array instead of FastList will take less memory and perform better.
>
> So, the main idea is to think about how the collection is being used and then choose the best class for it. Don't assume a Javolution class will always perform better.
>
> By the way, I'm not pointing any fingers or talking down to anyone here. I've done the copy-and-paste development myself. It's only recently that I started to scrutinize my choice of classes.
>
> -Adrian
>
>
> --- On Wed, 6/9/10, Adrian Crum <[hidden email]> wrote:
>> --- On Wed, 6/9/10, David E Jones
>> <[hidden email]>
>> 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
>>
>>
>>
>>
>>
>
>
>
URL: http://ofbiz.116.s1.nabble.com/EntityCondition-factory-objects-tp2249286p2249982.html
Interesting post but what I'm not hearing is any mention of specific downsides to using javolution in place of the util classes even when the use may not be taking advantage of any specific javolution features.
You mention this:
> There is no performance benefit to using FastList in this scenario. An ArrayList will use less memory and will perform faster than FastList - if its size is initialized to the correct value. Better yet, if you know the number of objects in advance, then just create an array.
But you provide no evidence to back the statement up. And a FastList can also be given an initial size.
I'm disagreeing with what you're saying because I really don't know much about it, but your post doesn't really do much to increase my knowledge or give me any reason to follow your advice.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 10/06/2010, at 6:25 PM, Adrian Crum wrote:
> I'm continuing this discussion with a new subject since the thread is starting to diverge from the original subject.
>
> A lot of the current code uses Javolution classes in many places for one common reason - copy-and-paste development. If you don't understand the Javolution library and its intended use and actual benefits then it's hard to know when the classes should be used and when there might be better alternatives.
>
> When I see class names like FastList and FastMap, I assume using them will speed up code. Indeed, some JRE class methods will execute faster using Javolution instead of JRE classes, and those methods are well documented on the Javolution website. If a bit of code doesn't use any of those methods, then there will be no benefit to using Javolution.
>
> Adam and I discussed earlier the use of object pools. Object pools used to improve performance because they helped cut down on garbage collection. Sun/Oracle recommends getting rid of object pools when using the newer versions of Java because the newer versions have improved garbage collectors.
>
> If you do a Google search for "java performance improvement" you'll get a lot of links to a lot of articles. From my experience a lot of those ideas are based on some special knowledge of how the JVM works and they "game the system" to improve performance. As a result, some of those optimizations depend on the JVM version and the platform it runs on.
>
> My preference is to use efficient algorithms and well structured code, and leave the performance optimizations to the JVM. I can give an example that will be obvious to everyone:
>
> Let's say a section of code builds a List of objects and then iterates over the List. Once the List is created, its contents don't change - there are no additions, removals, inserts, etc. In addition, this List will be a member of an object that is kept in a cache.
>
> There is no performance benefit to using FastList in this scenario. An ArrayList will use less memory and will perform faster than FastList - if its size is initialized to the correct value. Better yet, if you know the number of objects in advance, then just create an array.
>
> If an ArrayList is used, you can call the trimToSize method after the List is filled to reduce the memory it uses. Better yet, convert it to an array to reduce memory use even more. A cached object that contains an array instead of FastList will take less memory and perform better.
>
> So, the main idea is to think about how the collection is being used and then choose the best class for it. Don't assume a Javolution class will always perform better.
>
> By the way, I'm not pointing any fingers or talking down to anyone here. I've done the copy-and-paste development myself. It's only recently that I started to scrutinize my choice of classes.
>
> -Adrian
>
>
> --- On Wed, 6/9/10, Adrian Crum <[hidden email]> wrote:
>> --- On Wed, 6/9/10, David E Jones
>> <[hidden email]>
>> 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
>>
>>
>>
>>
>>
>
>
>
smime.p7s (3K) | Free forum by Nabble | Edit this page |