I do think it's definitely worthwhile trying this out. Looking at the history of javolution on their main page[1], they don't appear to have made much in the way of changes for at least 2 years and possibly up to 5, meanwhile the JDK/JVM continues to progress.
I was expecting to check the site and see that it was time for us to upgrade the library before doing any comparisons but things seem pretty stagnant. Regards Scott [1] http://javolution.org/ On 31/05/2012, at 6:33 PM, Adrian Crum wrote: > That's the thing - measuring performance can be tricky. A while back I ran > across some code that didn't use fixed-count loops, but instead ran the test > code through a loop indefinitely until the loop execution time stabilized - > then the stabilized time was used as the measurement. That approach seemed to > make the most sense to me. > > But I agree - before we remove it altogether we should run some performance > tests. > > -Adrian > > On 5/31/2012 7:27 AM, Jacopo Cappellato wrote: >> We could create a branch, convert the code there to remove javolution and >> then run some profiling on the two instances; we could define in advance >> (before starting the actual work) the tools and tests we will use to measure >> the performance. >> Then people will run the same tests in their own boxes (different platforms, >> hardware) and we will have a decent amount of data to take a more informed >> decision. >> Any idea for the tool? (JMeter etc...) >> >> Jacopo >> >> On May 31, 2012, at 7:37 AM, Adrian Crum wrote: >> >>> http://mail-archives.apache.org/mod_mbox/ofbiz-dev/201006.mbox/%3c2640abb5-65b1-4cb0-b360-2a97eac2e...@me.com%3E >>> >>> -Adrian >>> >>> On 5/31/2012 2:08 AM, Scott Gray wrote: >>>> Perhaps my memory is failing but haven't you raised this topic before? >>>> What was the outcome back then? >>>> >>>> I think if you're planning to rehash old topics then it's good to call out >>>> the previous discussions that have been had to give a full context. While >>>> I'm not at all suggesting you are doing this, it is entirely possible for >>>> someone with an agenda to keep raising old topics as new ones until the >>>> desired response is received from the community, later on when someone >>>> complains you can just say "but I discussed it first!" even if the idea >>>> had been rejected in several previous discussions. Again, I'm not >>>> suggesting you're doing this, just using it as an example of why it's >>>> important to disclose previous discussions when raising them anew. >>>> >>>> Regards >>>> Scott >>>> >>>> On 30/05/2012, at 11:24 PM, Adrian Crum wrote: >>>> >>>>> I am reposting this thread with a different subject to make sure everyone >>>>> interested has a chance to comment. >>>>> >>>>> To summarize (and to make sure we are all on the same page): >>>>> >>>>> 1. Javolution was added to the project in the JDK 1.4 days. David Jones >>>>> ran some performance tests that demonstrated a performance boost when >>>>> using Javolution Fast* classes instead of java.util.* classes. >>>>> 2. Javolution acheived this performance boost by eliminating some garbage >>>>> collection. The Fast* classes use object pools - where objects are >>>>> returned to the pool when they are unused instead of being garbage >>>>> collected. >>>>> 3. JDK 1.5 introduced an improved garbage collector that eliminated the >>>>> long pauses caused by previous garbage collectors. Also, it introduced >>>>> the java.util.concurrent package - which is functionally similar to >>>>> Javolution's concurrency. When OFBiz switched to the JDK 1.5 requirement, >>>>> the need for Javolution was eliminated - but it was kept in the project >>>>> anyway. >>>>> 4. No performance tests have been executed recently to see what kind of >>>>> impact removing Javolution will have. >>>>> 5. In the attached thread I recommend removing Javolution from object >>>>> fields that are effectively static (either declared static or a field of >>>>> an object that is cached indefinitely), because the pooled object is >>>>> never returned to the pool - defeating the purpose of the library. >>>>> 6. In the attached thread Adam suggests removing Javolution entirely. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> On 5/27/2012 9:56 PM, Adrian Crum wrote: >>>>>> On 5/27/2012 5:56 PM, Adam Heath wrote: >>>>>>> On 05/27/2012 07:09 AM, Jacques Le Roux wrote: >>>>>>>> From: "Adrian Crum"<adrian.c...@sandglass-software.com> >>>>>>>>> FYI, in the Mini-language overhaul I interned the Element tag name >>>>>>>>> Strings. >>>>>>>> Yes, that's really a good improvment! Things are much more clear now. >>>>>>>> It's only in minilang though (I mean not in widgets actions yet), >>>>>>>> right? >>>>>>>> >>>>>>>>> Another thing to discuss is the proper use of Javolution and/or >>>>>>>>> whether we still need it. >>>>>>>> Yes, I also wondered about that last week when willing to cast to a >>>>>>>> TreeMap. >>>>>>>> The fact that it's a one man project and will maybe less and less >>>>>>>> supported http://javolution.org/#HISTORY is not yet an issue but could >>>>>>>> be >>>>>>> I personally see no need for javolution. It's non-standard >>>>>>> concurrency(java.util.concurrent). It does it's own memory allocation, >>>>>>> which prevents escape-analysis from working(allocating memory on the >>>>>>> stack instead of the heap). >>>>>>> >>>>>> In the Mini-language overhaul I removed Javolution classes from model >>>>>> fields - since the models could be kept in memory (cached) indefinitely >>>>>> (resulting in borrowed objects that are never returned to the pool). I >>>>>> kept Javolution in the script execution path - which is the proper use >>>>>> from my perspective. I know you ran into issues with FastMap previously, >>>>>> but I don't remember the details. >>>>>> >>>>>> If there are no objections, I can remove Javolution from Mini-language >>>>>> entirely. >>>>>> >>>>>> -Adrian >>>>>>
