CODEWITHSUNDEEP
javaoptimizationprofiling
isquaredr
isquaredr

Reputation: 187

Efficiency of having logic in-line vs calling a method?

I currently have a disagreement going on with my 2nd year JAVA professor that I'm hoping y'all could help solve:

The code we started with was this:

   public T peek()
   {
       if (isEmpty())
       .........
   }
   public boolean isEmpty() 
   {
       return topIndex<0;
   }

And she wants us to remove the isEmpty() reference and place its code directly into the if statement (i.e. change the peek method contents to: if(topIndex<0).......) to "Make the code more efficient". I have argued that a) the runtime/compile time optimizer would most likely have inlined the isEmpty() call, b) even if it didn't, the 5-10 machine operations would be negligible in nearly every situation, and c) its just bad style because it makes the program less readable and less changeable.

So, I guess my question is: Is there any runtime efficiency gained by inlineing logic as opposed to just calling a method? I have tried simple profiling techniques (aka long loop and a stopwatch) but tests have been inconclusive.

EDIT:

Thank you everyone for the responses! I appreciate you all taking the time. Also, I appreciate those of you who commented on the pragmatism of arguing with my professor and especially doing so without data. @Mike Dunlavey I appreciate your insight as a former professor and your advice on the appropriate coding sequence. @ya_pulser I especially appreciate the profiling advice and links you took the time to share.

Upvotes: 12

Views: 1353

Answers (5)

JanKanis
JanKanis

Reputation: 6712

Another form of data to look at could be the code that is generated. See the -XX:+PrintAssembly option and friends. See How to see JIT-compiled code in JVM? for more information.

I'm confident that in this particular case the Hotspot JVM will inline the call to isEmpty and there would be no performance difference.

Upvotes: 0

Mike Dunlavey
Mike Dunlavey

Reputation: 40699

Sad...

I agree with your intuitions about it, especially "the 5-10 machine operations would be negligible in nearly every situation".

I was a C.S. professor a long time ago. On one hand, professors need all the slack you can give them. Teaching is very demanding. You can't have a bad day. If you show up for a class and you're not fully prepared, you're in for a rough ride. If you give a test on Friday and don't have the grades on Monday the students will say "But you had all weekend!" You can get satisfaction from seeing your students learn, but you yourself don't learn much, except how to teach.

On the other hand, few professors have much practical experience with real software. So their opinions tend to be founded on various dogmatic certitudes rather than solid pragmatism.

Performance is a perfect example of this. They tend to say "Don't do X. Do Y because it performs better." which completely misses the point about performance problems - you have to deal in fractions, not absolutes. Everything depends on what else is going on. The way to approach performance is, as someone said "First make it right. Then make it fast."

And the way you make it fast is not by eyeballing the code (and wondering "should I do this, or should I do that"), but by running it and letting it tell you how it's spending time. The basic idea of profiling is how you do this. Now there is such a thing as bad profiling and good profiling, as explained in the second answer here (and usually when professors do teach profiling, they teach the bad kind), but that's the way to go.

Upvotes: 8

ya_pulser
ya_pulser

Reputation: 2670

You are correct in your assumptions about java code behaviour, but you are impolite to your professor arguing without data :). Arguing without data is pointless, prove your assumptions with measurements and graphs.

You can use JMH ( http://openjdk.java.net/projects/code-tools/jmh/ ) to create a small benchmark and measure difference between:

  • inlined by hand (remove isEmpty method and place the code in call place)
  • inlined by java jit compiler (hotspot after 100k (?) invocations - see jit print compilation output)
  • disabled hotspot inlining at all

Please read http://www.oracle.com/technetwork/java/whitepaper-135217.html#method

Useful parameters could be:

  • -Djava.compiler=NONE
  • -XX:+PrintCompilation

Plus each jdk version has it's own set of parameters to control jit.

If you will create some set of graphics as results of your research and will politely present them to the professor - I think it will benefit you in future.

I think that https://stackoverflow.com/users/2613885/aleksey-shipilev can help with jmh related questions.

BTW: I had great success when I inlined plenty of methods into a single huge code loop to achieve maximum speed for neural network backpropagation routine cause java is (was?) too lazy to inline methods with methods with methods. It was unmaintainable and fast :(.

Upvotes: 10

janos
janos

Reputation: 124804

Calling isEmpty is idiomatic and nicely readable. Manually inlining that would be a micro optimization, something best done in performance critical situations, and after a bottleneck was confirmed by benchmarking in the intended production environment.

Is there a real performance benefit in manually inlining? Theoretically yes, and maybe that's what the lecture wanted to emphasize. In practice, I don't think you'll find an absolute answer. The automatic inlining behavior maybe implementation dependent. Also keep in mind that benchmark results will depend on JVM implementation, version, platform. And for that reason, this kind of optimization can be useful in rare extreme situations, and in general detrimental to portability and maintainability.

By the same logic, should we inline all methods, eliminating all indirections at the expense of duplicating large blocks of code? Definitely not. Where you draw the line exactly between decomposition and inlining may also depend on personal taste, to some degree.

Upvotes: 3

hugh
hugh

Reputation: 2280

As you say, the difference will be small, and in most circumstances the readability should be a higher priority. In this case though, since the extra method consists of a single line, I'm not sure this adds any real readability benefit unless you're calling the same method from elsewhere.

That said, remember that your lecturer's target is to help you learn computer science, and this is a different priority than writing production code. Particularly, she won't want you to be leaving optimization to automated tools, since that doesn't help your learning.

Also, just a practical note - in school and in professional development, we all have to adhere to coding standards we personally disagree with. It's an important skill, and really is necessary for team working, even if it does chafe.

Upvotes: 5

Related Questions