EntityCondition factory objects

[Adam Heath-2]

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.

[Adrian Crum]

"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

-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.
>

[Adam Heath-2]

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.
>>

[Adrian Crum]

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.
>>>
>
>

[Adam Heath-2]

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.
>>>>
>>
>>

[Adrian Crum]

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.
>>>>>
>>>
>>>
>
>

[David E. Jones-2]

On Jun 9, 2010, at 2: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.

Dang, I guess I missed that notification.

What's also cute is that no one else brought it up for five years. I wonder if there's a reason?

-David

[David E. Jones-2]

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?

If so, excellent! I can't wait to see the performance test code and the before and after comparisons for each change!

-David

[Adrian Crum-2]

--- 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

[Adrian Crum-2]

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
>
>
>
>
>

[Scott Gray-2]

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
>>
>>
>>
>>
>>
>
>
>

[Scott Gray-2]

Damn it, why is that I always miss key words in sentences?!?  Always has to be the one that if missing, completely reverses the message I intended to convey:

> 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.


I'm _NOT_ disagreeing with what you're saying...

Regards
Scott

On 10/06/2010, at 6:56 PM, Scott Gray wrote:

> 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
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>

[Adrian Crum-2]

I backed it up in an indirect way by mentioning the need to understand the Javolution library and its intended use. Go here to find out more:

http://javolution.org/

To summarize: Javolution was intended to be used in real-time systems where timing is critical. The library's goal is timing that is *consistent*, not necessarily fast.

OFBiz is not a real-time application - it isn't being used to control robots or Mars rovers or anything timing-critical like that.

You have to spend time on the Javolution site and poke around in their code a bit to understand the advantages/disadvantages. Adam has mentioned some of them in this thread and in previous threads.

FastList implements a doubly-linked list. The list nodes are kept in an object pool. ArrayList wraps an array. If you think about it, the advantages/disadvantages will start to become evident. FastList will perform additions and removals more consistently than ArrayList because the change involves adding/removing a node. ArrayList resizes/copies the array it wraps, so the timing depends on the size of the array. A doubly-linked list will take more memory than ArrayList because the list elements are wrapped with nodes. An ArrayList will take more memory than the array it wraps because it contains additional bookkeeping data.

-Adrian


--- On Wed, 6/9/10, Scott Gray <[hidden email]> wrote:

> From: Scott Gray <[hidden email]>
> Subject: Re: Discussion: When To Use Javolution (was: EntityCondition factory objects)
> To: [hidden email]
> Date: Wednesday, June 9, 2010, 11:56 PM
> 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
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>

[Adrian Crum-2]

Oops, I forgot to explain iteration differences. Iterating over an array is faster than traversing a doubly-linked list.

-Adrian

--- On Thu, 6/10/10, Adrian Crum <[hidden email]> wrote:

> I backed it up in an indirect way by
> mentioning the need to understand the Javolution library and
> its intended use. Go here to find out more:
>
> http://javolution.org/
>
> To summarize: Javolution was intended to be used in
> real-time systems where timing is critical. The library's
> goal is timing that is *consistent*, not necessarily fast.
>
> OFBiz is not a real-time application - it isn't being used
> to control robots or Mars rovers or anything timing-critical
> like that.
>
> You have to spend time on the Javolution site and poke
> around in their code a bit to understand the
> advantages/disadvantages. Adam has mentioned some of them in
> this thread and in previous threads.
>
> FastList implements a doubly-linked list. The list nodes
> are kept in an object pool. ArrayList wraps an array. If you
> think about it, the advantages/disadvantages will start to
> become evident. FastList will perform additions and removals
> more consistently than ArrayList because the change involves
> adding/removing a node. ArrayList resizes/copies the array
> it wraps, so the timing depends on the size of the array. A
> doubly-linked list will take more memory than ArrayList
> because the list elements are wrapped with nodes. An
> ArrayList will take more memory than the array it wraps
> because it contains additional bookkeeping data.
>
> -Adrian
>
>
> --- On Wed, 6/9/10, Scott Gray <[hidden email]>
> wrote:
>
> > From: Scott Gray <[hidden email]>
> > Subject: Re: Discussion: When To Use Javolution (was:
> EntityCondition factory objects)
> > To: [hidden email]
> > Date: Wednesday, June 9, 2010, 11:56 PM
> > 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
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
>
>
>
>

[David E. Jones-2]

On Jun 10, 2010, at 1:42 AM, Adrian Crum wrote:

> I backed it up in an indirect way by mentioning the need to understand the Javolution library and its intended use. Go here to find out more:
>
> http://javolution.org/
>
> To summarize: Javolution was intended to be used in real-time systems where timing is critical. The library's goal is timing that is *consistent*, not necessarily fast.
>
> OFBiz is not a real-time application - it isn't being used to control robots or Mars rovers or anything timing-critical like that.

That's hardly the only goal for Javolution, and certainly not the reason it is used in OFBiz. The main reasons were object pooling/reuse and faster Map (and sometimes List) performance for those that are pretty dynamic during their life (even if it is short).

> You have to spend time on the Javolution site and poke around in their code a bit to understand the advantages/disadvantages. Adam has mentioned some of them in this thread and in previous threads.
>
> FastList implements a doubly-linked list. The list nodes are kept in an object pool. ArrayList wraps an array. If you think about it, the advantages/disadvantages will start to become evident. FastList will perform additions and removals more consistently than ArrayList because the change involves adding/removing a node. ArrayList resizes/copies the array it wraps, so the timing depends on the size of the array. A doubly-linked list will take more memory than ArrayList because the list elements are wrapped with nodes. An ArrayList will take more memory than the array it wraps because it contains additional bookkeeping data.

There's really quite a bit more to it than that, ie lots of reasons to choose a linked list, doubly linked list, or an array (in Java either literal or array list).

However, for most of OFBiz chances are it won't make much of a difference in memory usage or execution time. The fact is these things do get complicated and it's nice to know about different options and what might work better in a certain circumstance, but just because in theory it might use less memory or execute faster doesn't mean that it actually will, or it might make a difference but not a measurable one by even a performance testing tool and certainly not something that even on a larger scale a user would notice because other factors dominate so much that such changes are little more than background noise.

That's why I brought up profiling. Again, for most of OFBiz (especially business logic) what it used won't make any significant difference. There may be a few places in the framework where things could be improved, but searching through the code for these trying to find patterns that _might_ perform worse than an alternative may make no change at all, or may even make things worse. Profiling will help you know if it really improved things, and will also help you find actual performance problems (memory use and execution time) instead of poking around in the dark.

Once a performance problem is found, then you can start experimenting with changes that will improve things, and then some of these ideas might be helpful. Until then, it's great to share information but IMO it is not actionable at all (or wise to act on any way with profiling, unless you have time to kill and aren't concerned about the risk of doing more harm than good).

-David

> --- On Wed, 6/9/10, Scott Gray <[hidden email]> wrote:
>
>> From: Scott Gray <[hidden email]>
>> Subject: Re: Discussion: When To Use Javolution (was: EntityCondition factory objects)
>> To: [hidden email]
>> Date: Wednesday, June 9, 2010, 11:56 PM
>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Adrian Crum-2]

--- On Thu, 6/10/10, David E Jones <[hidden email]> wrote:

> On Jun 10, 2010, at 1:42 AM, Adrian Crum wrote:
>
> > I backed it up in an indirect way by mentioning the
> need to understand the Javolution library and its intended
> use. Go here to find out more:
> >
> > http://javolution.org/
> >
> > To summarize: Javolution was intended to be used in
> real-time systems where timing is critical. The library's
> goal is timing that is *consistent*, not necessarily fast.
> >
> > OFBiz is not a real-time application - it isn't being
> used to control robots or Mars rovers or anything
> timing-critical like that.
>
> That's hardly the only goal for Javolution, and certainly
> not the reason it is used in OFBiz. The main reasons were
> object pooling/reuse and faster Map (and sometimes List)
> performance for those that are pretty dynamic during their
> life (even if it is short).
>
> > You have to spend time on the Javolution site and poke
> around in their code a bit to understand the
> advantages/disadvantages. Adam has mentioned some of them in
> this thread and in previous threads.
> >
> > FastList implements a doubly-linked list. The list
> nodes are kept in an object pool. ArrayList wraps an array.
> If you think about it, the advantages/disadvantages will
> start to become evident. FastList will perform additions and
> removals more consistently than ArrayList because the change
> involves adding/removing a node. ArrayList resizes/copies
> the array it wraps, so the timing depends on the size of the
> array. A doubly-linked list will take more memory than
> ArrayList because the list elements are wrapped with nodes.
> An ArrayList will take more memory than the array it wraps
> because it contains additional bookkeeping data.
>
> There's really quite a bit more to it than that, ie lots of
> reasons to choose a linked list, doubly linked list, or an
> array (in Java either literal or array list).

True. I was explaining the reasoning behind the choice in my example, I was not suggesting that choice should be applied to all of OFBiz.

> However, for most of OFBiz chances are it won't make much
> of a difference in memory usage or execution time. The fact
> is these things do get complicated and it's nice to know
> about different options and what might work better in a
> certain circumstance, but just because in theory it might
> use less memory or execute faster doesn't mean that it
> actually will, or it might make a difference but not a
> measurable one by even a performance testing tool and
> certainly not something that even on a larger scale a user
> would notice because other factors dominate so much that
> such changes are little more than background noise.
>
> That's why I brought up profiling. Again, for most of OFBiz
> (especially business logic) what it used won't make any
> significant difference. There may be a few places in the
> framework where things could be improved, but searching
> through the code for these trying to find patterns that
> _might_ perform worse than an alternative may make no change
> at all, or may even make things worse. Profiling will help
> you know if it really improved things, and will also help
> you find actual performance problems (memory use and
> execution time) instead of poking around in the dark.
>
> Once a performance problem is found, then you can start
> experimenting with changes that will improve things, and
> then some of these ideas might be helpful. Until then, it's
> great to share information but IMO it is not actionable at
> all (or wise to act on any way with profiling, unless you
> have time to kill and aren't concerned about the risk of
> doing more harm than good).
>
> -David
>
>
> > --- On Wed, 6/9/10, Scott Gray <[hidden email]>
> wrote:
> >
> >> From: Scott Gray <[hidden email]>
> >> Subject: Re: Discussion: When To Use Javolution
> (was: EntityCondition factory objects)
> >> To: [hidden email]
> >> Date: Wednesday, June 9, 2010, 11:56 PM
> >> 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>

[David E. Jones-2]

I'm sure there are good references around with a more complete list of differences. Be careful about pushing some differences and leaving out others, especially when bias is involved (ie arrays are better than linked lists). It may be that in some circumstances iterating is faster, but if so probably not by much (ie the difference between following a pointer versus incrementing an index).

There are some things that linked lists do far better (like sorting, and most modifications actually), and if not intentionally optimized they can actually require more memory instead of less for smaller lists.

To Scott's point... what (again) was the point of all of this? I guess it's always fun to thump one's chest and demonstrate knowledge of the concepts behind basic data structures, but most of this stuff fits into freshman computer science material, so even that isn't so much fun s not many people will be impressed.

To your point Adrian, this stuff is definitely an issue, but unless you're looking at a specific piece of code and you actually profile to test alternatives it's really quite difficult to guess at what is better.

That's part of the fun of profiling, the moment you find you were wrong is roughly the same moment when you find out what is right, even if it's often not what you expected. There are very few activities in life where those two events occur so close together... so it makes it kind of fun and only occasionally frustrating instead of the other way around... ;)

-David


On Jun 10, 2010, at 1:49 AM, Adrian Crum wrote:

> Oops, I forgot to explain iteration differences. Iterating over an array is faster than traversing a doubly-linked list.
>
> -Adrian
>
> --- On Thu, 6/10/10, Adrian Crum <[hidden email]> wrote:
>> I backed it up in an indirect way by
>> mentioning the need to understand the Javolution library and
>> its intended use. Go here to find out more:
>>
>> http://javolution.org/
>>
>> To summarize: Javolution was intended to be used in
>> real-time systems where timing is critical. The library's
>> goal is timing that is *consistent*, not necessarily fast.
>>
>> OFBiz is not a real-time application - it isn't being used
>> to control robots or Mars rovers or anything timing-critical
>> like that.
>>
>> You have to spend time on the Javolution site and poke
>> around in their code a bit to understand the
>> advantages/disadvantages. Adam has mentioned some of them in
>> this thread and in previous threads.
>>
>> FastList implements a doubly-linked list. The list nodes
>> are kept in an object pool. ArrayList wraps an array. If you
>> think about it, the advantages/disadvantages will start to
>> become evident. FastList will perform additions and removals
>> more consistently than ArrayList because the change involves
>> adding/removing a node. ArrayList resizes/copies the array
>> it wraps, so the timing depends on the size of the array. A
>> doubly-linked list will take more memory than ArrayList
>> because the list elements are wrapped with nodes. An
>> ArrayList will take more memory than the array it wraps
>> because it contains additional bookkeeping data.
>>
>> -Adrian
>>
>>
>> --- On Wed, 6/9/10, Scott Gray <[hidden email]>
>> wrote:
>>
>>> From: Scott Gray <[hidden email]>
>>> Subject: Re: Discussion: When To Use Javolution (was:
>> EntityCondition factory objects)
>>> To: [hidden email]
>>> Date: Wednesday, June 9, 2010, 11:56 PM
>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
>

[Adrian Crum-2]

My point was made since the beginning of the original thread. Javolution might not be the best choice in all situations. Let's discuss that.

As far as I can tell, no one here is thumping their chest. Adam asked a legitimate question. I pointed to an informative article related to his question. We discussed the premise of that article. I thought it would be helpful for the community to discuss it further. Scott asked for more information and I offered it. If any chest thumping was done, it was in your last reply.

-Adrian

--- On Thu, 6/10/10, David E Jones <[hidden email]> wrote:

> From: David E Jones <[hidden email]>
> Subject: Re: Discussion: When To Use Javolution (was: EntityCondition factory objects)
> To: [hidden email]
> Date: Thursday, June 10, 2010, 1:08 AM
>
> I'm sure there are good references around with a more
> complete list of differences. Be careful about pushing some
> differences and leaving out others, especially when bias is
> involved (ie arrays are better than linked lists). It may be
> that in some circumstances iterating is faster, but if so
> probably not by much (ie the difference between following a
> pointer versus incrementing an index).
>
> There are some things that linked lists do far better (like
> sorting, and most modifications actually), and if not
> intentionally optimized they can actually require more
> memory instead of less for smaller lists.
>
> To Scott's point... what (again) was the point of all of
> this? I guess it's always fun to thump one's chest and
> demonstrate knowledge of the concepts behind basic data
> structures, but most of this stuff fits into freshman
> computer science material, so even that isn't so much fun s
> not many people will be impressed.
>
> To your point Adrian, this stuff is definitely an issue,
> but unless you're looking at a specific piece of code and
> you actually profile to test alternatives it's really quite
> difficult to guess at what is better.
>
> That's part of the fun of profiling, the moment you find
> you were wrong is roughly the same moment when you find out
> what is right, even if it's often not what you expected.
> There are very few activities in life where those two events
> occur so close together... so it makes it kind of fun and
> only occasionally frustrating instead of the other way
> around... ;)
>
> -David
>
>
> On Jun 10, 2010, at 1:49 AM, Adrian Crum wrote:
>
> > Oops, I forgot to explain iteration differences.
> Iterating over an array is faster than traversing a
> doubly-linked list.
> >
> > -Adrian
> >
> > --- On Thu, 6/10/10, Adrian Crum <[hidden email]>
> wrote:
> >> I backed it up in an indirect way by
> >> mentioning the need to understand the Javolution
> library and
> >> its intended use. Go here to find out more:
> >>
> >> http://javolution.org/
> >>
> >> To summarize: Javolution was intended to be used
> in
> >> real-time systems where timing is critical. The
> library's
> >> goal is timing that is *consistent*, not
> necessarily fast.
> >>
> >> OFBiz is not a real-time application - it isn't
> being used
> >> to control robots or Mars rovers or anything
> timing-critical
> >> like that.
> >>
> >> You have to spend time on the Javolution site and
> poke
> >> around in their code a bit to understand the
> >> advantages/disadvantages. Adam has mentioned some
> of them in
> >> this thread and in previous threads.
> >>
> >> FastList implements a doubly-linked list. The list
> nodes
> >> are kept in an object pool. ArrayList wraps an
> array. If you
> >> think about it, the advantages/disadvantages will
> start to
> >> become evident. FastList will perform additions
> and removals
> >> more consistently than ArrayList because the
> change involves
> >> adding/removing a node. ArrayList resizes/copies
> the array
> >> it wraps, so the timing depends on the size of the
> array. A
> >> doubly-linked list will take more memory than
> ArrayList
> >> because the list elements are wrapped with nodes.
> An
> >> ArrayList will take more memory than the array it
> wraps
> >> because it contains additional bookkeeping data.
> >>
> >> -Adrian
> >>
> >>
> >> --- On Wed, 6/9/10, Scott Gray <[hidden email]>
> >> wrote:
> >>
> >>> From: Scott Gray <[hidden email]>
> >>> Subject: Re: Discussion: When To Use
> Javolution (was:
> >> EntityCondition factory objects)
> >>> To: [hidden email]
> >>> Date: Wednesday, June 9, 2010, 11:56 PM
> >>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>

[David E. Jones-2]

At least I'm willing to admit it... :)

-David


On Jun 10, 2010, at 2:18 AM, Adrian Crum wrote:

> My point was made since the beginning of the original thread. Javolution might not be the best choice in all situations. Let's discuss that.
>
> As far as I can tell, no one here is thumping their chest. Adam asked a legitimate question. I pointed to an informative article related to his question. We discussed the premise of that article. I thought it would be helpful for the community to discuss it further. Scott asked for more information and I offered it. If any chest thumping was done, it was in your last reply.
>
> -Adrian
>
> --- On Thu, 6/10/10, David E Jones <[hidden email]> wrote:
>
>> From: David E Jones <[hidden email]>
>> Subject: Re: Discussion: When To Use Javolution (was: EntityCondition factory objects)
>> To: [hidden email]
>> Date: Thursday, June 10, 2010, 1:08 AM
>>
>> I'm sure there are good references around with a more
>> complete list of differences. Be careful about pushing some
>> differences and leaving out others, especially when bias is
>> involved (ie arrays are better than linked lists). It may be
>> that in some circumstances iterating is faster, but if so
>> probably not by much (ie the difference between following a
>> pointer versus incrementing an index).
>>
>> There are some things that linked lists do far better (like
>> sorting, and most modifications actually), and if not
>> intentionally optimized they can actually require more
>> memory instead of less for smaller lists.
>>
>> To Scott's point... what (again) was the point of all of
>> this? I guess it's always fun to thump one's chest and
>> demonstrate knowledge of the concepts behind basic data
>> structures, but most of this stuff fits into freshman
>> computer science material, so even that isn't so much fun s
>> not many people will be impressed.
>>
>> To your point Adrian, this stuff is definitely an issue,
>> but unless you're looking at a specific piece of code and
>> you actually profile to test alternatives it's really quite
>> difficult to guess at what is better.
>>
>> That's part of the fun of profiling, the moment you find
>> you were wrong is roughly the same moment when you find out
>> what is right, even if it's often not what you expected.
>> There are very few activities in life where those two events
>> occur so close together... so it makes it kind of fun and
>> only occasionally frustrating instead of the other way
>> around... ;)
>>
>> -David
>>
>>
>> On Jun 10, 2010, at 1:49 AM, Adrian Crum wrote:
>>
>>> Oops, I forgot to explain iteration differences.
>> Iterating over an array is faster than traversing a
>> doubly-linked list.
>>>
>>> -Adrian
>>>
>>> --- On Thu, 6/10/10, Adrian Crum <[hidden email]>
>> wrote:
>>>> I backed it up in an indirect way by
>>>> mentioning the need to understand the Javolution
>> library and
>>>> its intended use. Go here to find out more:
>>>>
>>>> http://javolution.org/
>>>>
>>>> To summarize: Javolution was intended to be used
>> in
>>>> real-time systems where timing is critical. The
>> library's
>>>> goal is timing that is *consistent*, not
>> necessarily fast.
>>>>
>>>> OFBiz is not a real-time application - it isn't
>> being used
>>>> to control robots or Mars rovers or anything
>> timing-critical
>>>> like that.
>>>>
>>>> You have to spend time on the Javolution site and
>> poke
>>>> around in their code a bit to understand the
>>>> advantages/disadvantages. Adam has mentioned some
>> of them in
>>>> this thread and in previous threads.
>>>>
>>>> FastList implements a doubly-linked list. The list
>> nodes
>>>> are kept in an object pool. ArrayList wraps an
>> array. If you
>>>> think about it, the advantages/disadvantages will
>> start to
>>>> become evident. FastList will perform additions
>> and removals
>>>> more consistently than ArrayList because the
>> change involves
>>>> adding/removing a node. ArrayList resizes/copies
>> the array
>>>> it wraps, so the timing depends on the size of the
>> array. A
>>>> doubly-linked list will take more memory than
>> ArrayList
>>>> because the list elements are wrapped with nodes.
>> An
>>>> ArrayList will take more memory than the array it
>> wraps
>>>> because it contains additional bookkeeping data.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> --- On Wed, 6/9/10, Scott Gray <[hidden email]>
>>>> wrote:
>>>>
>>>>> From: Scott Gray <[hidden email]>
>>>>> Subject: Re: Discussion: When To Use
>> Javolution (was:
>>>> EntityCondition factory objects)
>>>>> To: [hidden email]
>>>>> Date: Wednesday, June 9, 2010, 11:56 PM
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>

[Scott Gray-2]

I will admit to thumping my chest and saying "ahhhhhhhh" at the same time.

But only after you guys mentioned it and only to bring back childhood memories.  Maybe I need some rest.

Regards
Scott

On 10/06/2010, at 8:23 PM, David E Jones wrote:

>
> At least I'm willing to admit it... :)
>
> -David
>
>
> On Jun 10, 2010, at 2:18 AM, Adrian Crum wrote:
>
>> My point was made since the beginning of the original thread. Javolution might not be the best choice in all situations. Let's discuss that.
>>
>> As far as I can tell, no one here is thumping their chest. Adam asked a legitimate question. I pointed to an informative article related to his question. We discussed the premise of that article. I thought it would be helpful for the community to discuss it further. Scott asked for more information and I offered it. If any chest thumping was done, it was in your last reply.
>>
>> -Adrian
>>
>> --- On Thu, 6/10/10, David E Jones <[hidden email]> wrote:
>>
>>> From: David E Jones <[hidden email]>
>>> Subject: Re: Discussion: When To Use Javolution (was: EntityCondition factory objects)
>>> To: [hidden email]
>>> Date: Thursday, June 10, 2010, 1:08 AM
>>>
>>> I'm sure there are good references around with a more
>>> complete list of differences. Be careful about pushing some
>>> differences and leaving out others, especially when bias is
>>> involved (ie arrays are better than linked lists). It may be
>>> that in some circumstances iterating is faster, but if so
>>> probably not by much (ie the difference between following a
>>> pointer versus incrementing an index).
>>>
>>> There are some things that linked lists do far better (like
>>> sorting, and most modifications actually), and if not
>>> intentionally optimized they can actually require more
>>> memory instead of less for smaller lists.
>>>
>>> To Scott's point... what (again) was the point of all of
>>> this? I guess it's always fun to thump one's chest and
>>> demonstrate knowledge of the concepts behind basic data
>>> structures, but most of this stuff fits into freshman
>>> computer science material, so even that isn't so much fun s
>>> not many people will be impressed.
>>>
>>> To your point Adrian, this stuff is definitely an issue,
>>> but unless you're looking at a specific piece of code and
>>> you actually profile to test alternatives it's really quite
>>> difficult to guess at what is better.
>>>
>>> That's part of the fun of profiling, the moment you find
>>> you were wrong is roughly the same moment when you find out
>>> what is right, even if it's often not what you expected.
>>> There are very few activities in life where those two events
>>> occur so close together... so it makes it kind of fun and
>>> only occasionally frustrating instead of the other way
>>> around... ;)
>>>
>>> -David
>>>
>>>
>>> On Jun 10, 2010, at 1:49 AM, Adrian Crum wrote:
>>>
>>>> Oops, I forgot to explain iteration differences.
>>> Iterating over an array is faster than traversing a
>>> doubly-linked list.
>>>>
>>>> -Adrian
>>>>
>>>> --- On Thu, 6/10/10, Adrian Crum <[hidden email]>
>>> wrote:
>>>>> I backed it up in an indirect way by
>>>>> mentioning the need to understand the Javolution
>>> library and
>>>>> its intended use. Go here to find out more:
>>>>>
>>>>> http://javolution.org/
>>>>>
>>>>> To summarize: Javolution was intended to be used
>>> in
>>>>> real-time systems where timing is critical. The
>>> library's
>>>>> goal is timing that is *consistent*, not
>>> necessarily fast.
>>>>>
>>>>> OFBiz is not a real-time application - it isn't
>>> being used
>>>>> to control robots or Mars rovers or anything
>>> timing-critical
>>>>> like that.
>>>>>
>>>>> You have to spend time on the Javolution site and
>>> poke
>>>>> around in their code a bit to understand the
>>>>> advantages/disadvantages. Adam has mentioned some
>>> of them in
>>>>> this thread and in previous threads.
>>>>>
>>>>> FastList implements a doubly-linked list. The list
>>> nodes
>>>>> are kept in an object pool. ArrayList wraps an
>>> array. If you
>>>>> think about it, the advantages/disadvantages will
>>> start to
>>>>> become evident. FastList will perform additions
>>> and removals
>>>>> more consistently than ArrayList because the
>>> change involves
>>>>> adding/removing a node. ArrayList resizes/copies
>>> the array
>>>>> it wraps, so the timing depends on the size of the
>>> array. A
>>>>> doubly-linked list will take more memory than
>>> ArrayList
>>>>> because the list elements are wrapped with nodes.
>>> An
>>>>> ArrayList will take more memory than the array it
>>> wraps
>>>>> because it contains additional bookkeeping data.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> --- On Wed, 6/9/10, Scott Gray <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> From: Scott Gray <[hidden email]>
>>>>>> Subject: Re: Discussion: When To Use
>>> Javolution (was:
>>>>> EntityCondition factory objects)
>>>>>> To: [hidden email]
>>>>>> Date: Wednesday, June 9, 2010, 11:56 PM
>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>