• Post Reply Bookmark Topic Watch Topic
  • New Topic

javap  RSS feed

 
Chris Montgomery
Ranch Hand
Posts: 141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm always looking to improve my code's performance and was recently exposed to javap -c.

very cool.

But I don't think I understand it yet...

Two methods:


returns this:


Does this really mean that testOne will take longer and is less efficient?

The reason I ask is because my testTwo calles a static method from another class. The logic that is taking place in that static method is identical to the code found in testOne. I'm confused. I guess I would have expected them to be the same or testOne to take less.

Here is the code of my static method:


Thanks!
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The disassembly of the second method shows the static method being called. That means that at runtime, the code you're seeing here, plus the code in the static method, both run. In total, that will represent more bytecodes than your first version, in which everything is done inline.

I'm confused, though -- did you not already know this about methods (that the code for each method is kept separately, and calling a method just transfers control at runtime, and doesn't imply that the code for the method is copied everyplace it is called?)
 
Chris Montgomery
Ranch Hand
Posts: 141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
At risk of sounding extremely naive, I haven't ever thought about byte code or how to proactively make my code more efficient before for that matter. If it works, why bother caring? As I gain more experience and knowledge of Java (and a sickness of wanting the most efficient code), I�m beginning to get it. ☺

Back to item at hand:
I just saw javap for the first time the other day. Someone was trying to figure out what was more efficient. I said to use a timestamp and was quickly shoed off stage. Another person recommended javap. From there I deduced that the one with less lines is "more efficient" not realizing what you have pointed out.


So, even though there are less lines in testTwo, this does not imply that testTwo has less steps to execute.

Reviewing the output:


should I read "invokestatic #30; //�" on line 1 to mean a count of 30 steps take place at this point in the code?
[ October 23, 2005: Message edited by: Chris Montgomery ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The "#30" refers to item number 30 in the "constant pool", a data structure in the class file that stores things like Strings, numbers, the names of other classes, the names of methods, etc. The "invokestatic" bytecode calls a method; "invokestatic #30" means to call the static method described by entry #30 in the constant pool. That method is your "isNullOrEmpty()" method -- you can use javap to disassemble the class it appears in, as well. To know how many instructions testTwo() really takes, you have to add the ones directly in testTwo() to the count in the method isNullOrEmpty().

Counting instructions isn't a very good way to tell how long a method will take, by the way, as some instructions take much less time than others -- of course, the exact differences will vary by JVM implementation. javap is a good way to find out what various language constructs really mean -- for example write a method that does some String catenation with "+" and then decompile it to find out what happens. Or maybe more surprising: find out what an array declaration like

int[] ia = { 1, 2, 3, 4, 5 };

compiles into!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
Counting instructions isn't a very good way to tell how long a method will take, by the way, as some instructions take much less time than others -- of course, the exact differences will vary by JVM implementation.


In the example above, it might actually take exactly the same time, if the JVM decides to inline the static method call.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Chris Montgomery:
a sickness of wanting the most efficient code


The word "sickness" was choosen very wisely here...

Seriously, what is much more important than performance is maintainability and extensibility - that's what decides how costly a project becomes.

For performance, the 80:20 rule applies: 20% of the code are responsible for 80% of the performance. (Actually the real numbers might be different, such as 90:10, but you get the idea.) So the most important part of improving the performance of a system is to find those 20%. Guessing them is almost never going to work - you will need to use a profiler to find them, and often enough you will be surprised at what you find.
 
Chris Montgomery
Ranch Hand
Posts: 141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This makes a ton of sense.
Can you recommend a good open source profiler?
 
Chris Montgomery
Ranch Hand
Posts: 141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm using Eclipse and just used their profiler.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!