harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Cornwall (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5682) [classlib][pack200] Sped up hashCode and removed dead getCpAll()
Date Wed, 02 Apr 2008 18:39:28 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-5682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584716#action_12584716

Andrew Cornwall commented on HARMONY-5682:

I didn't do that because I assumed the overhead of the exception handler would be too much.
But it's worth a try - so I just did. Here are the results for my testcase:

CpClass 0.685 3.066
Without exception handler: 0.685 s
With exception handler: 3.066 s

Without exception handler: 1.204 s
With exception handler: 1.873 s

Without exception handler: 2.323 s
With exception handler: 6.761 s

In other words, with exception handlers our time for hashCode almost doubles. Since hashCode
accounts for slightly more than 10% of the total time of the test case with the exception
handlers and less than 4% without, I'm inclined to leave the exceptions uncaught.

I do agree the code is hokey, though.

> [classlib][pack200] Sped up hashCode and removed dead getCpAll()
> ----------------------------------------------------------------
>                 Key: HARMONY-5682
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5682
>             Project: Harmony
>          Issue Type: Improvement
>          Components: Classlib
>         Environment: All Pack200
>            Reporter: Andrew Cornwall
>         Attachments: main.patch
> This patch does two things, one of which may be controversial.
> The uncontroversial code removes SegmentConstantPool.getCpAll(), since it is no longer
> The other code changes hashCode in CPUTF8, CPClass and CPRef. Because hashCode is used
frequently, making it fast is a good idea. In the pack200 code as it exists, hashCode is never
called for CPUTF8, CPClass or CPRef unless all instance variables have been set. The changes
to hashCode make the assumption that this will always hold. As a consequence, hashCode will
throw a NullPointerException when sent to uninitialized instances of these classes.
> The changes to hashCode do improve runtime by about 10%.

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

View raw message