Java Performance Services
Training, Seminars, Benchmarking, Tuning

Java Performance Tuning Course


Chania Crete, May 17-20, 2010


Sun Extreme Learning EXL-2025

Houston, December 1-4,2009
New York, December 8-11, 2009
Washington DC, January 5-8, 2010



San Francisco, January 11-14

Anti-if

I have joined Anti-IF Campaign

Calendar

««Nov 2009»»
SMTWTFS
1234
5
67
891011121314
15161718192021
22232425262728
2930

Performance Anti-Patterns

My Top Tags

                                       

Mailing List

My RSS Feeds








Declaring Methods final improves performance... NOT!

posted Saturday, 18 October 2008

I just read again on a Java Tips site (one that I'm not going to direct traffic to by giving you a URL) the performance advice backed up by a reasonable sounding explanation. The advice is; declaring methods to be final improves performance by allowing the compiler to inline the method. Before you go off littering your code with the final keyword expecting a whooping gain in performance you'd best consider this.

The brief explination is that final is a clue to the compiler that there will be no other implementations. If there are no other implementations then the compiler can inline the method into the calling method thus eliminating the virtual method call. If variables have been declared final, the compiler can also inline those values directly into the code.

What the advice ignores is that the optimizing compiler aggressively inlines method calls. The decision to inline is based on information gathered from the run time, not by the presence of the keyword final. The compiler not only aggressively inlines the monomorphic case pointed out in the tip, it also is able to produce code for the inlining of bimorphic and trimorpic calls.

The real hurt that comes with this bogus tip is when you decide that you want to extend or override something that has been declared final. You won't be able to! So while there are some good reasons to use 'final', promoting method inlining isn't one of them.

tags:                




1. Gregg Sporar left...
Saturday, 18 October 2008 7:45 pm :: http://blogs.sun.com/gregg

Hi Kirk. Excellent post - I am bummed to hear that there are resources out there that *still* offer that advice. This article by Brian Goetz: http://www.ibm.com/developerworks/java/library/j-jtp1029.html, does the best job I have ever seen of summarizing the correct use of final, and it was published in *2002* for cryin' out loud! HTH, Gregg


2. raveman left...
Saturday, 18 October 2008 8:10 pm

what about final params for methods? I think IntilliJ said it improve performance. However i think that when you improve performance outside of your database you are crazy.


3. William Louth left...
Saturday, 18 October 2008 8:41 pm

Agreed. The final keyword should be a default.

William


4. William Louth left...
Saturday, 18 October 2008 8:43 pm :: http://www.jinspired.com

By the way final does improve performance when viewed from a macro level and not a micro level. The less inheritance the better, ;-).


5. Kirk Pepperdine left...
Sunday, 19 October 2008 8:36 am

I don' t know of a good performance reason to justify the use of final anywhere. Doesn't final in a method parameter only clear up visibility issues for inner=classes? Another case for final is non-mutability in multi-core multi-threading. But rather than me repeating Brian's article I'd take Greggs suggestion and just to read that ariticle. And while you're there, go read Brian's words on GC, object pooling and oh gosh.. just go read the whole series ;-)

And William, Inheritance is not evil, just mis-used. Oh how I wish String wasn't declared final because proper inheritance there would clean up all that mess to due to unicode/ascii/multi-byte Strings and how is all fits into the JDK. But since someone decided that Java developers were not smart enough to understand fly-weights, they decided to play mother and keep us all safe. No pain, no gain!


6. Mikko Kauppila left...
Friday, 2 January 2009 6:55 am :: http://uttumuttu.blogspot.com

Asking whether final or non-final methods are faster is a mislead question. The essential point is that final methods can never be slower than non-final methods. Increasing provability of your code can never hurt performance.

Code provability is (non-strictly) monotonic: the more facts the compiler/runtime knows about the code, the more (or at least no less) potential optimizations it can deduce. Your argument is based on the current implementation of JVMs; my argument is based on universal logic.

The only reasons why providing more facts about your code can (paradoxically) hurt performance are:

1) Checking the facts themselves consumes more time than the resulting optimizations save.

2) The resulting optimizations turn out to actually be non-optimizations. (For example, eager heap deallocation leading to memory fragmentation.)