|
I was told by a colleague that in Java, the performance may be worse if we create more methods, stacking many methods calling over them in JVM, specially in a Java EE environment. This seems to somewhat defeat the concept of object oriented programming. Like if we write long methods - what isn't good for code readability - we can achieve more performance due to less methods in JVM stack. This is a correct affirmation? |
||||
closed as unclear what you're asking by gnat, MichaelT, GlenH7, Kilian Foth, ratchet freak Sep 11 '14 at 11:26Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question. |
||||
|
It's probabbly an wrong assumption, first as common sense nested calls shouldn't have any (measurable) performance hit at all. After doing some research you'll find that the JVM can do some optimizations in your code "automagically": And more importantly: As you can see:
So probabbly, if you as programmer can say "hey, one big method is better than nesting tons of other methods", the JIT/JVM/javac can figure that for you and fix it >>IF<< it's worth. I think that unless you get some numeric statistics, you are fine with tons of methods instead a monolithic piece of software. |
|||||||||||||||||||||
|
|
The JVM have this thing called JIT, which would optimize the application's code with various techniques. One of those is called "inline optimization". In this particular optimization, the JIT will automatically inline methods when needed, so, you might lost some processor cycles in this particular instant, even if it does, it's not sufficient to justify this kind of argument in my opinion. It's always nice to remember that usually the performance hotspots are the I/O and database access. Also nice to remember that, nowadays, machine time is cheap and developer's time are expensive. Further reading: |
|||
|
|
|
As others said, in Java its generally better to use lot of short methods, because they are JITed and inlined better. But it's plausible that in EE enviroment situation can be different. At least for method that are not simply called, but there is aditional overhead because of 1) Transaction handling, 2) Interceptors 3) EJB remote calls (stay away from highly granual remote calls) But if you split large method into multiple private methods, these overheads should not happen. tl,dr: Method call itself is not problem, additional overhead is (and you have controll over it) PS: I would not even consider NOT splitting methods for performance reasons untill proven there actually is some performance problem. With clearer code you usually achieve better performance, because you much easier identify parts that are 1) not actually needed 2) are called multiple times with same result |
|||
|
|
-XX:MaxInlineSize=#and-XX:CompileThreshold=#in the Hotspot JVM. nerds-central.blogspot.com/2009/09/… along with blog.leenarts.net/2010/05/26/dontcompilehugemethods are good reads too. You have some misconceptions about how things are working under the covers. – MichaelT Sep 12 '14 at 20:46