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-5907) [classlib][pack200]CPUTF8.hashCode() is slow
Date Mon, 14 Jul 2008 18:00:31 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613388#action_12613388
] 

Andrew Cornwall commented on HARMONY-5907:
------------------------------------------

I would suggest at least one change: have the generateHashCode() method assign the cachedHashCode.
Right now, users will have to write code like this:

// I want to assign the hashCode
cachedHashCode = generateHashCode();

It's possible (and in fact I did the following) when updating a class:

// I want to assign the hashCode
generateHashCode();
// at this point hashCodeComputed == true, but cachedHashCode is not yet assigned.


> [classlib][pack200]CPUTF8.hashCode() is slow
> --------------------------------------------
>
>                 Key: HARMONY-5907
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5907
>             Project: Harmony
>          Issue Type: Improvement
>    Affects Versions: 5.0M6
>         Environment: Latest pack200
>            Reporter: Andrew Cornwall
>            Assignee: Sian January
>         Attachments: main.patch, pack200-hashcodes-v1.patch
>
>
> The unpack process spends a lot of time doing CPUTF8.hashCode() - which does String.hashCode().
We can save about 1.5 seconds of my 39 second test case (about 4%) by caching the hashCode.
(I thought we did this before - or maybe I dreamt it?)

-- 
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