1

A frame of a thread stack is created when a method is called, and creating stack frames have negative effect to the performance of a java program. I want to know how much effect it is?

As I know, refactoring codes often leads to separating a method call into more than one method call, and I think it leads to increment method call count in the end. So, is it true that the ways of refactoring with separating method calls have negative effect to performance of java programs to be refactored?

For example:

Before refactored:

public class MyClassA {
    public void doTask1(){
       // here is very verbose code
    }
}

After refactored:

public class MyClassA {
    public void doTask1(){
        taskPart1();
        taskPart2();
        taskPart3();
    }
    public void taskPart1(){
        // do something that used to be in doTask1..
    }
    public void taskPart2(){
        // do something that used to be in doTask1..
    }
    public void taskPart3(){
        // do something that used to be in doTask1..
    }
}
ParkCheolu
  • 1,175
  • 2
  • 14
  • 30
  • 1
    If you are talking about refactoring in general, which means: restructuring the code in a different way (whatever that may be), then this question has no meaningful answer. It totally depends on the details of how exactly you are refactoring it. Method calls do have some overhead, but "refactoring" does not always mean that there will be more method calls. Also, the JVM inlines simple methods so that there is no method call overhead. – Jesper Jan 26 '17 at 13:55
  • @SteveSmith Oh, thank you for notifying me of that question. I think I have to delete it. – ParkCheolu Jan 26 '17 at 14:09
  • It might even *improve* the performance, if there’s a difference at all. You likely refactor code into separate methods because a) it’s used more than once, so the common code has a higher chance of getting optimized, to the benefit of all callers or b) the original code was too big, so the refactored code might benefit from the fact that the JVM’s optimizer is better with smaller methods. But the difference for a single method is likely hidden in the noise of other factors. – Holger Jan 26 '17 at 16:10

1 Answers1

2

The method call overhead is by far not significant enough to warrant any premature optimization / worries about performance. It's definitely not significant enough to prevent you from creating and calling methods where they have good semantic meaning.

Plus, the compiler might even inline them.

Buying better hardware is almost always cheaper then dealing with bugs introduced in the name of better performance. This is kind of idea behind many aspects of Java (think array bounds check).

Jiri Tousek
  • 12,211
  • 5
  • 29
  • 43
  • I rather disagree. The method call overhead is rather big for trivial methods (especially getters). But wherever it matters, the trivial method gets inlined, so there's zero overhead. +++ That said, I agree with your conclusion. – maaartinus Jan 26 '17 at 18:13