Removing Javolution
Locked
 
|
A discussion from about a year ago:
http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%3C42B94A35-C72F-4C83-8E7E-FC97FB37DDB1@...%3E I can create a branch and start working on this. Does anyone want to help? -Adrian |
|
|
Hi Adrian,
I would like help on this one. On 29 Mar 2013 16:58, "Adrian Crum" <[hidden email]> wrote: > A discussion from about a year ago: > > http://mail-archives.apache.**org/mod_mbox/ofbiz-dev/201205.** > mbox/%3C42B94A35-C72F-4C83-**8E7E-FC97FB37DDB1@hotwaxmedia.**com%3E<http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%3C42B94A35-C72F-4C83-8E7E-FC97FB37DDB1@...%3E> > > I can create a branch and start working on this. Does anyone want to help? > > -Adrian > > |
|
|
Cool - thanks!
https://svn.apache.org/repos/asf/ofbiz/branches/2013_RemoveJavolution -Adrian On 3/29/2013 11:46 AM, Varun Bhansaly wrote: > Hi Adrian, > > I would like help on this one. > On 29 Mar 2013 16:58, "Adrian Crum" <[hidden email]> > wrote: > >> A discussion from about a year ago: >> >> http://mail-archives.apache.**org/mod_mbox/ofbiz-dev/201205.** >> mbox/%3C42B94A35-C72F-4C83-**8E7E-FC97FB37DDB1@hotwaxmedia.**com%3E<http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%3C42B94A35-C72F-4C83-8E7E-FC97FB37DDB1@...%3E> >> >> I can create a branch and start working on this. Does anyone want to help? >> >> -Adrian >> >> |
|
|
Let me know your ideas or where/ what to start with and I will submitting
patches in JIRA. On 29 Mar 2013 17:27, "Adrian Crum" <[hidden email]> wrote: > Cool - thanks! > > https://svn.apache.org/repos/**asf/ofbiz/branches/2013_**RemoveJavolution<https://svn.apache.org/repos/asf/ofbiz/branches/2013_RemoveJavolution> > > -Adrian > > On 3/29/2013 11:46 AM, Varun Bhansaly wrote: > >> Hi Adrian, >> >> I would like help on this one. >> On 29 Mar 2013 16:58, "Adrian Crum" <adrian.crum@sandglass-**software.com<[hidden email]> >> > >> wrote: >> >> A discussion from about a year ago: >>> >>> http://mail-archives.apache.****org/mod_mbox/ofbiz-dev/201205.**** >>> mbox/%3C42B94A35-C72F-4C83-****8E7E-FC97FB37DDB1@hotwaxmedia.****com%3E< >>> http://mail-archives.**apache.org/mod_mbox/ofbiz-dev/** >>> 201205.mbox/%3C42B94A35-C72F-**4C83-8E7E-FC97FB37DDB1@** >>> hotwaxmedia.com%3E<http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%3C42B94A35-C72F-4C83-8E7E-FC97FB37DDB1@...%3E> >>> > >>> >>> I can create a branch and start working on this. Does anyone want to >>> help? >>> >>> -Adrian >>> >>> >>> > |
|
|
I was thinking a general workflow might be:
1. Work on framework components first. a. Remove static instances of Javolution objects. b. Remove other uses of Javolution objects. 2. Work on application components. 3. Work on special purpose, themes, etc last. 4. Run memory-use and performance tests. -Adrian On 3/29/2013 12:00 PM, Varun Bhansaly wrote: > Let me know your ideas or where/ what to start with and I will submitting > patches in JIRA. > On 29 Mar 2013 17:27, "Adrian Crum" <[hidden email]> > wrote: > >> Cool - thanks! >> >> https://svn.apache.org/repos/**asf/ofbiz/branches/2013_**RemoveJavolution<https://svn.apache.org/repos/asf/ofbiz/branches/2013_RemoveJavolution> >> >> -Adrian >> >> On 3/29/2013 11:46 AM, Varun Bhansaly wrote: >> >>> Hi Adrian, >>> >>> I would like help on this one. >>> On 29 Mar 2013 16:58, "Adrian Crum" <adrian.crum@sandglass-**software.com<[hidden email]> >>> wrote: >>> >>> A discussion from about a year ago: >>>> http://mail-archives.apache.****org/mod_mbox/ofbiz-dev/201205.**** >>>> mbox/%3C42B94A35-C72F-4C83-****8E7E-FC97FB37DDB1@hotwaxmedia.****com%3E< >>>> http://mail-archives.**apache.org/mod_mbox/ofbiz-dev/** >>>> 201205.mbox/%3C42B94A35-C72F-**4C83-8E7E-FC97FB37DDB1@** >>>> hotwaxmedia.com%3E<http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%3C42B94A35-C72F-4C83-8E7E-FC97FB37DDB1@...%3E> >>>> I can create a branch and start working on this. Does anyone want to >>>> help? >>>> >>>> -Adrian >>>> >>>> >>>> |
|
|
In reply to this post by Adrian Crum-3
Thank you Adrian
Jacopo On Mar 29, 2013, at 12:29 PM, Adrian Crum <[hidden email]> wrote: > A discussion from about a year ago: > > http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%3C42B94A35-C72F-4C83-8E7E-FC97FB37DDB1@...%3E > > I can create a branch and start working on this. Does anyone want to help? > > -Adrian > |
|
|
Thinking about this more, I don't think a branch will work. Javolution
is pervasive and it will take a while to remove it all. This will cause a lot of problems keeping the branch up to date with the trunk - due to merge conflicts (which will grow over time). I removed Javolution from Mini-language and ran the complete test suite - which includes a lot of tests written in Mini-language. There was no difference in execution time between the trunk version and the version that had Javolution removed. On a side note, I already removed a lot of Javolution instances during the Mini-language overhaul, and the overhaul improved performance by 40% - not because I removed Javolution, but through better code quality. I have tried to run profiling tools on OFBiz, but either the profiler crashes or OFBiz crashes. Visual VM will make it half way through the full test suite, then OFBiz just stops running. Looking at the performance report, it seems we should worry more about code hot spots than a potential performance hit from removing Javolution. So, I don't know how to proceed. Has anyone had any success with running profilers on OFBiz? -Adrian On 3/29/2013 12:42 PM, Jacopo Cappellato wrote: > Thank you Adrian > > Jacopo > > On Mar 29, 2013, at 12:29 PM, Adrian Crum <[hidden email]> wrote: > >> A discussion from about a year ago: >> >> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%3C42B94A35-C72F-4C83-8E7E-FC97FB37DDB1@...%3E >> >> I can create a branch and start working on this. Does anyone want to help? >> >> -Adrian >> |
|
|
On Mar 30, 2013, at 5:46 PM, Adrian Crum <[hidden email]> wrote: > Thinking about this more, I don't think a branch will work. Javolution is pervasive and it will take a while to remove it all. This will cause a lot of problems keeping the branch up to date with the trunk - due to merge conflicts (which will grow over time). I agree that performing this task in the trunk would make our life easier; as a side note, I am ready to commit some changes to disable selectively the specialpurpose components: as we discussed we could even exclude them from the build/test process by default (the idea is that maintaining them is "optional" i.e. it is ok to commit code to framework/applications that breaks them but of course we are happy to accept contributions to make specialpurpose component work)... in this way we could concentrate on a smaller codebase (framework and applications). Jacopo > > I removed Javolution from Mini-language and ran the complete test suite - which includes a lot of tests written in Mini-language. There was no difference in execution time between the trunk version and the version that had Javolution removed. On a side note, I already removed a lot of Javolution instances during the Mini-language overhaul, and the overhaul improved performance by 40% - not because I removed Javolution, but through better code quality. > > I have tried to run profiling tools on OFBiz, but either the profiler crashes or OFBiz crashes. Visual VM will make it half way through the full test suite, then OFBiz just stops running. Looking at the performance report, it seems we should worry more about code hot spots than a potential performance hit from removing Javolution. > > So, I don't know how to proceed. Has anyone had any success with running profilers on OFBiz? > > -Adrian > > On 3/29/2013 12:42 PM, Jacopo Cappellato wrote: >> Thank you Adrian >> >> Jacopo >> >> On Mar 29, 2013, at 12:29 PM, Adrian Crum <[hidden email]> wrote: >> >>> A discussion from about a year ago: >>> >>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%3C42B94A35-C72F-4C83-8E7E-FC97FB37DDB1@...%3E >>> >>> I can create a branch and start working on this. Does anyone want to help? >>> >>> -Adrian >>> > |
|
|
On 3/31/2013 8:06 AM, Jacopo Cappellato wrote:
> On Mar 30, 2013, at 5:46 PM, Adrian Crum <[hidden email]> wrote: > >> Thinking about this more, I don't think a branch will work. Javolution is pervasive and it will take a while to remove it all. This will cause a lot of problems keeping the branch up to date with the trunk - due to merge conflicts (which will grow over time). > I agree that performing this task in the trunk would make our life easier; as a side note, I created the branch to address the concerns in the previous discussion about the performance impact of removing Javolution. In other words, the branch is intended to be used with profilers before the changes are brought into the trunk. I don't think there will be any adverse effects of removing Javolution - because I understand how it did its 'magic' in the Java versions prior to 1.5. So, I need to find a way to convince others before I would be willing to do the work in the trunk. > I am ready to commit some changes to disable selectively the specialpurpose components: as we discussed we could even exclude them from the build/test process by default (the idea is that maintaining them is "optional" i.e. it is ok to commit code to framework/applications that breaks them but of course we are happy to accept contributions to make specialpurpose component work)... in this way we could concentrate on a smaller codebase (framework and applications). Hmmm... I think I prefer removing Javolution from specialpurpose before we remove specialpurpose. > > Jacopo > >> I removed Javolution from Mini-language and ran the complete test suite - which includes a lot of tests written in Mini-language. There was no difference in execution time between the trunk version and the version that had Javolution removed. On a side note, I already removed a lot of Javolution instances during the Mini-language overhaul, and the overhaul improved performance by 40% - not because I removed Javolution, but through better code quality. >> >> I have tried to run profiling tools on OFBiz, but either the profiler crashes or OFBiz crashes. Visual VM will make it half way through the full test suite, then OFBiz just stops running. Looking at the performance report, it seems we should worry more about code hot spots than a potential performance hit from removing Javolution. >> >> So, I don't know how to proceed. Has anyone had any success with running profilers on OFBiz? >> >> -Adrian >> >> On 3/29/2013 12:42 PM, Jacopo Cappellato wrote: >>> Thank you Adrian >>> >>> Jacopo >>> >>> On Mar 29, 2013, at 12:29 PM, Adrian Crum <[hidden email]> wrote: >>> >>>> A discussion from about a year ago: >>>> >>>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201205.mbox/%3C42B94A35-C72F-4C83-8E7E-FC97FB37DDB1@...%3E >>>> >>>> I can create a branch and start working on this. Does anyone want to help? >>>> >>>> -Adrian >>>> |
|
|
On Mar 31, 2013, at 11:09 AM, Adrian Crum <[hidden email]> wrote: > I created the branch to address the concerns in the previous discussion about the performance impact of removing Javolution. In other words, the branch is intended to be used with profilers before the changes are brought into the trunk. I don't think there will be any adverse effects of removing Javolution - because I understand how it did its 'magic' in the Java versions prior to 1.5. So, I need to find a way to convince others before I would be willing to do the work in the trunk. > One good reason for removing Javolution is that it doesn't seem that the project is actively maintained anymore (even if I see that they are now working on a new release, after several years). By the way, when dealing with profiling/benchmarking you may find this useful: http://blog.javabenchmark.org/2013/02/benchmarking-with-junitbenchmark.html >> I am ready to commit some changes to disable selectively the specialpurpose components: as we discussed we could even exclude them from the build/test process by default (the idea is that maintaining them is "optional" i.e. it is ok to commit code to framework/applications that breaks them but of course we are happy to accept contributions to make specialpurpose component work)... in this way we could concentrate on a smaller codebase (framework and applications). > > Hmmm... I think I prefer removing Javolution from specialpurpose before we remove specialpurpose. It is fine; just let me clarify that I didn't mention to remove specialpurpose from the trunk (only from the new release branch), only to disable some components. Jacopo |
|
|
Thanks for the link, but that kind of benchmark is not applicable here.
This article best describes our scenario: http://www.ibm.com/developerworks/java/library/j-jtp01274/index.html We won't know the performance difference until after Javolution is completely removed from the project - and here's why: When the Javolution classes are loaded, their object pools are created. For FastMap about 7 MB, and for FastList about 7MB. So we have these big chunks of memory being held by Javolution that can't be used by other objects. As a result, the garbage collector has to work harder to keep memory available for other objects. When Javolution is removed completely, then we recover that 14MB of memory and the garbage collector is invoked less. Until that happens, I don't think we will see any change. -Adrian On 4/2/2013 6:23 PM, Jacopo Cappellato wrote: > On Mar 31, 2013, at 11:09 AM, Adrian Crum <[hidden email]> wrote: > >> I created the branch to address the concerns in the previous discussion about the performance impact of removing Javolution. In other words, the branch is intended to be used with profilers before the changes are brought into the trunk. I don't think there will be any adverse effects of removing Javolution - because I understand how it did its 'magic' in the Java versions prior to 1.5. So, I need to find a way to convince others before I would be willing to do the work in the trunk. >> > One good reason for removing Javolution is that it doesn't seem that the project is actively maintained anymore (even if I see that they are now working on a new release, after several years). > By the way, when dealing with profiling/benchmarking you may find this useful: > > http://blog.javabenchmark.org/2013/02/benchmarking-with-junitbenchmark.html > >>> I am ready to commit some changes to disable selectively the specialpurpose components: as we discussed we could even exclude them from the build/test process by default (the idea is that maintaining them is "optional" i.e. it is ok to commit code to framework/applications that breaks them but of course we are happy to accept contributions to make specialpurpose component work)... in this way we could concentrate on a smaller codebase (framework and applications). >> Hmmm... I think I prefer removing Javolution from specialpurpose before we remove specialpurpose. > It is fine; just let me clarify that I didn't mention to remove specialpurpose from the trunk (only from the new release branch), only to disable some components. > > Jacopo > |
|
|
In reply to this post by Adrian Crum-3
I noticed that UtilMisc.toSet method has been refactored by replacing Javolution's FastSet with Java's HashSet.
But there's at least one thing worthy noted: FastSet keeps insertion order, HashSet not. So I think it's better to use LinkedHashSet instead of HashSet. One issue I know that was introduced by refactoring and caused by "insertion order" explained above is that GenericDAO.selectCountByCondition() will return unpredictable result if you : 1. set distinct option 2. call eli = delegator.find(entityName, whereEntityCondition, havingEntityCondition, fieldsToSelect, orderBy, findOptions); 3. eli.getPartialList(start, number) 4. int resultSize = eli.getResultsSizeAfterPartialList(); // it will then call GenericDAO.selectCountByCondition() which will generate counting sql like "COUNT(DISTINCT " + firstSelectField + ")" to get the result size. Note that the type of "fieldsToSelect" parameter of delegator.find method is "Set". When use FastSet, the firstSelectField mentioned above is exactly same as the first one defined by "fieldsToSelect". But for HashSet, there's NO FIRST one since it has no order. |
|
|
In reply to this post by Adrian Crum-3
I noticed that UtilMisc.toSet method has been refactored by replacing
Javolution's FastSet with Java's HashSet. But there's at least one thing worthy noted: FastSet keeps insertion order, HashSet not. So I think it's better to use LinkedHashSet instead of HashSet. One issue I know that was introduced by refactoring and caused by "insertion order" explained above is that GenericDAO.selectCountByCondition() will return unpredictable result if you : 1. set distinct option 2. call eli = delegator.find(entityName, whereEntityCondition, havingEntityCondition, fieldsToSelect, orderBy, findOptions); 3. eli.getPartialList(start, number) 4. int resultSize = eli.getResultsSizeAfterPartialList(); // it will then call GenericDAO.selectCountByCondition() which will generate counting sql like "COUNT(DISTINCT " + firstSelectField + ")" to get the result size. Note that the type of "fieldsToSelect" parameter of delegator.find method is "Set". When use FastSet, the firstSelectField mentioned above is exactly same as the first one defined by "fieldsToSelect". But for HashSet, there's NO FIRST one since it has no order. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Removing-Javolution-tp4640229p4644284.html Sent from the OFBiz - Dev mailing list archive at Nabble.com. |
|
|
Fixed in rev 1527212. Thanks Leon!
Adrian Crum Sandglass Software www.sandglass-software.com On 9/28/2013 8:00 AM, Leon wrote: > I noticed that UtilMisc.toSet method has been refactored by replacing > Javolution's FastSet with Java's HashSet. > > But there's at least one thing worthy noted: FastSet keeps insertion order, > HashSet not. So I think it's better to use LinkedHashSet instead of HashSet. > > One issue I know that was introduced by refactoring and caused by "insertion > order" explained above is that GenericDAO.selectCountByCondition() will > return unpredictable result if you : > 1. set distinct option > 2. call eli = delegator.find(entityName, whereEntityCondition, > havingEntityCondition, fieldsToSelect, orderBy, findOptions); > 3. eli.getPartialList(start, number) > 4. int resultSize = eli.getResultsSizeAfterPartialList(); // it will then > call GenericDAO.selectCountByCondition() which will generate counting sql > like "COUNT(DISTINCT " + firstSelectField + ")" to get the result size. > > Note that the type of "fieldsToSelect" parameter of delegator.find method is > "Set". When use FastSet, the firstSelectField mentioned above is exactly > same as the first one defined by "fieldsToSelect". But for HashSet, there's > NO FIRST one since it has no order. > > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble.com/Removing-Javolution-tp4640229p4644284.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |