Thanks Xiao-Feng and Yunan, Degradation for pmd benchmark disappeared. The results for gcv5 are similar to gcv4. Unfortunately hsqldb and xalan benches still fail. HARMONY-3899 was created to track it.
Thanks. Vladimir. On 5/16/07, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
I've committed. Thanks, xiaofeng On 5/16/07, yunan He <[EMAIL PROTECTED]> wrote: > Hi vladimir, > The lower performance in GCv5 was due to the hashcode implementation, I > have created JIRA-3875 and attached a patch to solve the issue. Would you > please test the dacapo again after the patch committed? In my local test, > the most hashcode-intensive app "pmd" has comparable performance > now. Thanks. > > Regards, > Yunan > > > On 5/16/07, Vladimir Strigun <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > Since default gc was changed to gcv5, I've done performance comparison > > between gcv4 and gcv5 with Dacapo benchmark. The next build was used: > > svn = r538104, (May 15 2007), Windows/ia32/msvc 1310, release build. > > Measurements were performed on Woodcrest machine, with 900M heap, > > large pages off. As the addition for the current code I used new > > charset encoders/decoders[1]. Each Dacapo benchmarks were executed 10 > > times, final result calculated from last 5 values. I got the following > > numbers (the values are in milliseconds, so the less the better): > > > > gc_cc.dll: > > antlr 1762 > > bloat: 5927 (the benchmark failed after 6th iteration) > > chart: 7831 > > fop: 1043 > > hsqldb: 2290 > > jython: 6790 > > luindex: 5422 > > lusearch: 2846 > > pmd: 4071 > > xalan: 2087 > > > > gc_gen.dll: > > antlr: 2354 (the benchmark failed after 7th iteration) > > bloat: 6005 (the benchmark failed after 6th iteration) > > chart: 7812 > > fop: 1034 > > hsqldb: 2219 (the benchmark failed after 6th iteration) > > jython: 6072 > > luindex: 5478 > > lusearch: 3569 > > pmd: 27772 > > xalan: 4547 (failed after 3rd iteration) > > > > So, as the result we have 3 new failures (benchmarks not completed > > successfully), huge degradation for pmd benchmark, degradation for > > lusearch benchmark and significant speedup for jython. I'll continue > > to play with gcv5 - increase heap size, turn on large pages, etc. > > Should I create 3 separate JIRA issues for each failure or one issue > > is enough? > > > > > > Thanks. > > Vladimir. > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-3593 > > > -- http://xiao-feng.blogspot.com
