refactoring, final keyword and JVM tuning

[Udayan Patel]

Just wondering, How many of people make use of final keyword or make use of final keyword effectively on your methods and method parameters?

[Ilja Preuss]

I use the final keyword for communication reasons - and because it's needed when using anonymous inner classes.

I've never used it for performance reasons.

[Jeanne Boyarsky]

Udayan,
I use final for local variables as appropriate (for communication reasons as well.) I also use final for methods as appropriate, but only when I am positive something shouldn't be extended.

I don't use final for method parameters. However, the method parameters are implicitly final in that we have a tool that flags if you try to assign something to one. So it is safe for us to assume that all method parameters are final.

[Udayan Patel]

Have you guys ever ever tried to use final with method for performance reasons? try it, specially with the methods ranges from 15 to 20 statements.

[Ilja Preuss]

Originally posted by Udayan Patel:
Have you guys ever ever tried to use final with method for performance reasons? try it, specially with the methods ranges from 15 to 20 statements.

I prefer to not have methods that big.

Did you try? What did you encounter?

[Udayan Patel]

Originally posted by Ilja Preuss:


I prefer to not have methods that big.

Did you try? What did you encounter?

we all have to make methods big sometimes. however, I have tried it several times, very significant difference in execution of code and use of memory. Although this doesn't apply where method size is huge. e.g. persistance methods. perticularly where your method doesn't change parameters try making them final explicitly.

[Jeanne Boyarsky]

Udayan,
While my goal is to have smaller methods, I find 15-20 lines to be a reasonable maximum. Having said that, it isn't worth it for me to add the final keyword. It would only yield a small performance improvement, if any, compared to database accesses and the like. Further, it would make it harder for me to use Eclipse's "extract method refactoring" because I would have to remember to add the final by hand.

"particularly where your method doesn't change parameters try making them final explicitly." - Methods should never change parameters. This is a poor practice that makes code brittle and harder to understand.

[Udayan Patel]

Originally posted by Jeanne Boyarsky:
Udayan,
While my goal is to have smaller methods, I find 15-20 lines to be a reasonable maximum. Having said that, it isn't worth it for me to add the final keyword. It would only yield a small performance improvement, if any, compared to database accesses and the like. Further, it would make it harder for me to use Eclipse's "extract method refactoring" because I would have to remember to add the final by hand.

point well taken. But don't you think if you are executing a method in a loop it would be a quite a bit performance gain? Not sure I should describe this but here is the excerpt on how JVM operates on final methods:
"If you make a method final, you are allowing the compiler to turn any calls to that method into inline calls. When the compiler sees a final method call it can (at its discretion) skip the normal approach of inserting code to perform the method call mechanism (push arguments on the stack, hop over to the method code and execute it, hop back and clean off the stack arguments, and deal with the return value) and instead replace the method call with a copy of the actual code in the method body. This eliminates the overhead of the method call."

"particularly where your method doesn't change parameters try making them final explicitly." - Methods should never change parameters. This is a poor practice that makes code brittle and harder to understand.

probably not!, I am not sure how many times you change parameters while you have small mathods. we all break down our code to small methods because each method is suppose to check the parameters and do something, most of the time, we don't change value of it. Well I should be speaking for myself. Pretty much most of the time my code is that way.
[ January 26, 2005: Message edited by: Udayan Patel ]

[Jeanne Boyarsky]

Originally posted by Udayan Patel:
But don't you think if you are executing a method in a loop it would be a quite a bit performance gain?

Still no. I do agree that there is a small performance gain. Say I have a loop that calls a method 1 million times. Even if I can recover a few milliseconds from this optimization, my database accesses take five seconds. I am better off tuning that.

I am more aware of making a method final when it may be extendable than of a performance benefit that doesn't help me. Obviously, if the loop you speak of is proven to be a performance bottleneck, it should be tuned. However, I would consider making it final at that point, not at the beginning.

[Ilja Preuss]

Originally posted by Jeanne Boyarsky:

I am more aware of making a method final when it may be extendable

Ditto - I often use final for Template Methods, for example.

[Ilja Preuss]

Originally posted by Udayan Patel:
"If you make a method final, you are allowing the compiler to turn any calls to that method into inline calls. When the compiler sees a final method call it can (at its discretion) skip the normal approach of inserting code to perform the method call mechanism (push arguments on the stack, hop over to the method code and execute it, hop back and clean off the stack arguments, and deal with the return value) and instead replace the method call with a copy of the actual code in the method body. This eliminates the overhead of the method call."

This is a quote from "Thinking in Java", and it has a footnote in the book, which says:

Don�t fall prey to the urge to prematurely optimize. If you get your system working and it�s too slow, it�s doubtful that you can fix it with the final keyword. However, Chapter 15 has information about profiling, which can be helpful in speeding up your program.

Additionally, the information is somewhat outdated - the modern hotspot engine *is* able to even inline non-final methods.

[Sathya Srinivasan]

The golden rule is 'make it work. make it right. make it fast (or optimal)'. As Jeanne said, there are probably other areas that need more attention. I have seen significant performance gains typically by tuning my collections (using the right collection at the right place) and by checking the number of objects that I create (especially in loops).

I have used final for methods only when I know that it should not be overridden and classes for the same reason. I haven't given much thought to the performance gain. It was mostly done as a form of documentation.