3

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.

So, write many methods who call and interact with each other is worse to performance than write a few long methods to use less stacks in JVM? Is this is a correct affirmation?

closed as unclear what you're asking by gnat, user40980, GlenH7, Kilian Foth, ratchet freak Sep 11 '14 at 11:26

Please 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.

5

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":

Adaptive Optimization

And more importantly:

Inline Expansion

As you can see:

In computing, inline expansion, or inlining, is a manual or compiler optimization that replaces a function call site with the body of the callee

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.

  • 2
    There is no such thing as common sense, especially in software development. – whatsisname Sep 9 '14 at 19:00
  • Indeed @whatsisname. Maybe I didn't express myself well enough, you can read that as "today, with the current computing power, nested calls [...]" – Israel Fonseca Sep 9 '14 at 19:28
  • Common sense is critical to good software development, but there is (still) nothing more uncommon than common sense. – david.pfx Sep 10 '14 at 1:34
  • 1
    @david.pfx: Common sense is a phrase used as shorthand for "if you disagree with me you're an idiot" – whatsisname Sep 10 '14 at 16:43
  • 1
    @whatsisname: Indeed "recourse to commonsense" is bogus, but real commonsense is what you recognise in others who tend to make good guesses. It's what tells me that this is the wrong place for this argument. – david.pfx Sep 11 '14 at 9:30
3

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:

2

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.