harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4891) [drlvm][gc] heap exhaustion performance is five times slower than RI's one
Date Thu, 11 Oct 2007 06:23:50 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-4891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533963
] 

Alexei Fedotov commented on HARMONY-4891:
-----------------------------------------

Hmm, ok, my fault. With your numbers we get only x3.48 speed difference, not x5. In any case
46495 / 87478 = 0.53 < 0.7.

> [drlvm][gc] heap exhaustion performance is five times slower than RI's one
> --------------------------------------------------------------------------
>
>                 Key: HARMONY-4891
>                 URL: https://issues.apache.org/jira/browse/HARMONY-4891
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Windows, ia32
>            Reporter: Alexei Fedotov
>            Assignee: Xiao-Feng Li
>         Attachments: AbstractTest.java, GcTest.java, p-unit-0.12.jar, p-unit-extension-0.12.jar
>
>
> $ time win_ia32_msvc_release/deploy/jdk/jre/bin/java -cp bin/classes org.apache.harmony.test.stress.gc.share.GcTest
> [concurrent] Starting org.apache.harmony.test.stress.gc.share.GcTest
> [debug] total = 268435456, used = 2165188, ratio = 13, sizes = 1 - 2097152
> test() - [123709.342995ms,97.95109033584595%]
> total: 1, failures:0 (GREEN) - 123770.125835ms
> real    2m9.328s
> user    0m0.015s
> sys     0m0.000s
> $ time java -cp bin/classes org.apache.harmony.test.stress.gc.share.GcTest
> [concurrent] Starting org.apache.harmony.test.stress.gc.share.GcTest
> [debug] total = 66650112, used = 142120, ratio = 13, sizes = 1 - 2097152
> test() - [47643.880758ms,92.48719041912487%]
> total: 1, failures:0 (GREEN) - 47670.789275ms
> real    0m47.953s
> user    0m0.015s
> sys     0m0.000s
> The test itself runs exactly 30sec, and most of the time is taken by single-threaded
heap exhaustions to estimate the maximum size available for allocation.
> 1. It would be great to get within 70% of RI performance.
> 2. It would be great if one tunes debug build performance which is currently x40 times
slower. The debug build is used for regular stress test runs and this would help to save some
time.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message