Well, I have a quick patch with moving to HashMap. It gives +8% to unpacking scenario, available in JIRA.
Thanks, Aleksey. On Tue, Jul 8, 2008 at 1:41 PM, Aleksey Shipilev <[EMAIL PROTECTED]> wrote: > This method is the hell for performance. > It is not only accounts for 15% of CPU time, but instrumentation also shows: > - average size of array is 4700 elements > - 99% times the search traverses entire array and finds nothing > > We should consider move to *Map here :) > > Thanks, > Aleksey. > > On Tue, Jul 8, 2008 at 1:30 PM, Sian January <[EMAIL PROTECTED]> wrote: >> The purpose of this code is to get the class constant pool ordering right, >> so that if a signature string has already been transmitted in the CpUtf8 >> band it has the correct global index. However it might be possible to do >> the search a different way if this method is taking a long time. E.g if I >> get rid of the code that differentiates between signatures and other Ascii >> values (i.e. replace all occurrences of >> ClassConstantPool.DOMAIN_SIGNATUREASCIIZ >> with ClassConstantPool.DOMAIN_NORMALASCIIZ) then my tests seem to pass, >> although Andrew you wrote that code so it might be that I'm not testing all >> the cases where this is needed. Also there might be worse performance >> implications from making that change, but I can attach a patch to the JIRA >> if you would like to test it. >> >> >> >> On 08/07/2008, Aleksey Shipilev (JIRA) <[EMAIL PROTECTED]> wrote: >>> >>> >>> [ >>> https://issues.apache.org/jira/browse/HARMONY-5900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611488#action_12611488] >>> >>> Aleksey Shipilev commented on HARMONY-5900: >>> ------------------------------------------- >>> >>> From my measurements for 20Mb .jar.pack.gz file on Sun JDK 1.6.0_05 >>> -server, CPBands.search accounts for 15% of CPU time. >>> Let's move the discussion to dev. >>> >>> > [classlib][pack200] CpBands.parseCpSignature(Ljava/io/InputStream;) is >>> hot >>> > >>> -------------------------------------------------------------------------- >>> > >>> > Key: HARMONY-5900 >>> > URL: https://issues.apache.org/jira/browse/HARMONY-5900 >>> > Project: Harmony >>> > Issue Type: Wish >>> > Components: Classlib >>> > Affects Versions: 5.0M6 >>> > Environment: All Pack200 HEAD >>> > Reporter: Andrew Cornwall >>> > >>> > The method >>> org/apache/harmony/unpack200/CpBands.parseCpSignature(Ljava/io/InputStream;) >>> appears to be very hot. I tried initially to optimize it by caching some of >>> its arrays: >>> > static void clearArrayCache() { >>> > arrayCache = new SegmentConstantPoolArrayCache(); >>> > } >>> > >>> > private static SegmentConstantPoolArrayCache arrayCache = new >>> SegmentConstantPoolArrayCache(); >>> > >>> > private int search(String[] array, String string) { >>> > if(array.length > 30) { >>> > List indexes = arrayCache.indexesForArrayKey(array, >>> string); >>> > if (indexes.size() == 0) { >>> > return -1; >>> > } >>> > return ((Integer)indexes.get(0)).intValue(); >>> > } else { >>> > for (int i = 0; i < array.length; i++) { >>> > if(array[i].equals(string)) { >>> > return i; >>> > } >>> > } >>> > return -1; >>> > } >>> > } >>> > ... but that didn't appear to increase performance. (Maybe all the >>> searches are done once?) >>> > Any ideas how to tune parseCpSignature to get it faster? >>> >>> -- >>> This message is automatically generated by JIRA. >>> - >>> You can reply to this email to add a comment to the issue online. >>> >>> >> >> >> -- >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >
