×

Discussion Board

Results 1 to 5 of 5
  1. #1
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113

    Methods, that take lots of space

    I am doing MIDlet optimization, trying to fit all the things in 64Kb.
    While doing it I constantly reingineer various methods.

    Is there any way or tool to analyze class files, to show which methods consume lots of space?

  2. #2
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395
    I just use this:

    javap -c ClassName | findstr "^Method return$"

    It just gives a list of method names, and the offset to any return instructions - the last one of which will be the last instruction in the method, so gives you a fair indication of the method size. (It doesn't take account of exception tables, but it's a reasonably good guide to which methods are huge.)

  3. #3
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113
    graham
    Could you give some live example?

    I never used javap.
    Javap itself gives me a list of methods without any offsets.
    passing it to findstr doesnt give any ouput at all

  4. #4
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395
    javap extracts a variety of data from java class files. You can get an overview of the options with javap -help. To use with many MIDlet classes, you may have to add in a reference to the MIDP API classes. That would be something like:

    javap -bootclasspath C:\apps\WTK104\wtklib\emptyapi.zip MyClass

    The -c option provides disassembly of the methods. (I also often use the -l option to map method offsets (from exception reports) into line-numbers.)

    For example, I have an implementation of StringTokenizer that I use in MIDlets, as it's missing from the MIDP API. If I use:

    javap -c StringTokenizer

    I get an output like:

    Method boolean hasMoreElements()
    0 aload_0
    1 invokevirtual #17 <Method boolean hasMoreTokens()>
    4 ireturn

    Method java.lang.Object nextElement()
    0 aload_0
    1 invokevirtual #16 <Method java.lang.String nextToken()>
    4 areturn

    and so on. findstr is the NT equivalent of Unix's grep. I've given two patterns: ^Method - which pulls out any line starting with the text "Method"; and return$ - which pulls out any line ending with the text "return". (The ^ matches the start of a line, $ matches the end). findstr is case-sensitive. So:

    javap -c StringTokenizer | findstr "^Method return$"

    lists:

    Method StringTokenizer(java.lang.String,java.lang.String,boolean)
    79 return
    Method StringTokenizer(java.lang.String,java.lang.String)
    7 return
    Method StringTokenizer(java.lang.String)
    8 return
    Method int findNextTokenStart(int)
    87 ireturn
    Method boolean hasMoreTokens()
    16 ireturn
    Method java.lang.String nextToken()
    95 areturn
    Method java.lang.String nextToken(java.lang.String)
    9 areturn
    Method int countTokens()
    28 ireturn
    Method boolean hasMoreElements()
    4 ireturn
    Method java.lang.Object nextElement()
    4 areturn

    Since the numbers listed are the offsets (in bytes) to the instruction, and the last instruction in each method is always a return (unless anyone knows otherwise!), this gives you some idea of the size of the method code. (There are sometimes multiple "return"s in a method, but the last one is still the last instruction).

    It doesn't tell the whole story. In my tests, I find that a method with a single character name, no parameters and no code (the compiler will still generate a return instruction) increases the size of a class file by 33 bytes. And javap does not list constant-pool entries - it is difficult to include these in method size evaluations, as they are often shared between methods (where two methods include the same String constant, or invoke the same external method, for example).

    Graham.

  5. #5
    Registered User
    Join Date
    Jul 2003
    Location
    Finland, Tampere
    Posts
    1,113
    graham
    Thanx a lot! Sounds like useful practice.
    I also tried searching web for some tools, that would automate and simplify procedure.

    Found this free Code Explorer :
    http://www.codexterity.com/classexp.htm

    Basically it shows length of class methods and other class information.

    If you got used to javap, it might be not very attractive for you, but novises in disassembly should definetely consider this tool.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×