And the sorted list: 95462388 bc.cputf8 18646908 bc.bytecode 15118425 bc.cpclass 14928914 bc.cpnametype 12103799 bc.cpmethref 5159994 bc.cpfieldref 3420605 bc.methref 1840965 bc.cpstring 839916 bc.codeattr 839916 bc.locvarattr 839916 bc.linenumattr 430234 bc.cpmethod 277144 bc.cpfield 263753 bc.attr 153811 bc.cpinteger 121856 bc.newattr 93471 bc.cvalattr 72492 bc.excpattr 57428 bc.srcfileattr 57428 bc.srcfileattr 48104 bc.cplong 40362 bc.innerclass 5593 bc.depattr 3255 bc.cpfloat 1638 bc.cpdouble 532 attrlayout 0 archive 0 attrdef 0 newattrband 0 bc.anndefarg 0 bc.rtannattr 0 classbands 0 filebands 0 metabandgr 0 segheader 0 bc.remattr 0 bc.annattr 0 bc.cpconst 0 bc.cpmember 0 bc.signattr 0 bandset 0 bcbands 0 cpbands 0 icbands 0 ictuple 0 segment 0 segopts 0 bc.classf 0 bc.cpref 0 bc.opmgr 0 bc.rtattr 0 segcp 0 bc.ccp 0 attrlayoutmap 0 bc.encmethattr 0 bc.exptableent 0 bc.locvartable 0 bc.signattr
Thanks, Aleksey. On Sat, Jul 12, 2008 at 1:50 PM, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > Hi, Andrew! > > I had updated the internal profiler to support hashCode() probes [1], > to extend your effort in hashcode optimization. There are bunch of > heavily used hashcodes, most of them are going to Object.hashCode() > and then to System.identityHashCode(). We can cache/implement hashcode > for these classes. Here's the profile: > > Hashcodes: > archive: 0 > attrdef: 0 > attrlayout: 532 > attrlayoutmap: 0 > bandset: 0 > bcbands: 0 > classbands: 0 > cpbands: 0 > filebands: 0 > icbands: 0 > ictuple: 0 > metabandgr: 0 > newattrband: 0 > segcp: 0 > segheader: 0 > segment: 0 > segopts: 0 > bc.attr: 263753 > bc.remattr: 0 > bc.anndefarg: 0 > bc.annattr: 0 > bc.bytecode: 18646908 > bc.ccp: 0 > bc.classf: 0 > bc.codeattr: 839916 > bc.cvalattr: 93471 > bc.cpclass: 15118425 > bc.cpconst: 0 > bc.cpdouble: 1638 > bc.cpfield: 277144 > bc.cpfieldref: 5159994 > bc.cpfloat: 3255 > bc.cpinteger: 153811 > bc.methref: 3420605 > bc.cplong: 48104 > bc.cpmember: 0 > bc.cpmethod: 430234 > bc.cpmethref: 12103799 > bc.cpnametype: 14928914 > bc.cpref: 0 > bc.cpstring: 1840965 > bc.cputf8: 95462388 > bc.depattr: 5593 > bc.encmethattr: 0 > bc.excpattr: 72492 > bc.exptableent: 0 > bc.innerclass: 40362 > bc.linenumattr: 839916 > bc.locvarattr: 839916 > bc.locvartable: 0 > bc.newattr: 121856 > bc.opmgr: 0 > bc.rtattr: 0 > bc.rtannattr: 0 > bc.signattr: 0 > bc.srcfileattr: 57428 > > Would you like to produce the patch? > I think it would be funny :) > > Thanks, > Aleksey. > > [1] https://issues.apache.org/jira/browse/HARMONY-5905 > > On Sat, Jul 12, 2008 at 12:48 AM, Andrew Cornwall (JIRA) > <[EMAIL PROTECTED]> wrote: >> >> [ >> https://issues.apache.org/jira/browse/HARMONY-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Andrew Cornwall updated HARMONY-5907: >> ------------------------------------- >> >> Attachment: main.patch >> >> main.patch includes change to CPUTF8.java >> >> >>> [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 >>> Attachments: main.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. >> >> >
