I want to know that many developers do the same thing as to decrease the size of long method , they create so many small sized methods from it for the same task. I want to know that does it affects the performance of an application or not?
-
1it doesn't affect the perf since it's translated to machine language (difference of nano seconds!!) – Incepter Nov 10 '16 at 10:46
-
A method should avoid repertitive code, and also, respect the chaine of responsibility pattern – Incepter Nov 10 '16 at 10:47
-
1If your adding a methods its should add value to the behavior of the Class. But adding only methods without any value or purpose which doesn't define the behavior it doesn't makes sense. All the methods go on stack it should not have any performance issues. – BholaVishwakarma Nov 10 '16 at 10:51
-
1@BholaVishwakarma: Adding private methods in order to keep the logic short, targeted, and comprehensible is a well-established rule for maintainability. – T.J. Crowder Nov 10 '16 at 10:52
-
I agree with you @T.J.Crowder still that can be done having a static methods in a separate class which only have the purpose of dividing the logic without impacting the real Class attributes and Behaviour – BholaVishwakarma Nov 10 '16 at 10:53
2 Answers
Functions should normally be short, between 5-15 lines is my personal "rule of thumb" when coding in Java or C#. This is a good size for several reasons:
- It fits easily on your screen without scrolling
- It's about the conceptual size that you can hold in your head
- It's meaningful enough to require a function in its own right (as a standalone, meaningful chunk of logic)
- A function smaller than 5 lines is a hint that you are perhaps breaking the code up too much (which makes it harder to read / understand if you need to navigate between functions). Either that or your're forgetting your special cases / error handling!
But I don't think it is helpful to set an absolute rule, as there will always be valid exceptions / reasons to diverge from the rule:
- A one-line accessor function that performs a type cast is clearly acceptable in some situations.
- There are some very short but useful functions (e.g. swap as mentioned by user unknown) that clearly need less than 5 lines. Not a big deal, a few 3 line functions don't do any harm to your code base.
- A 100-line function that is a single large switch statement might be acceptable if it is extremely clear what is being done. This code can be conceptually very simple even if it requires a lot of lines to describe the different cases. Sometimes it is suggested that this should be refactored into separate classes and implemented using inheritance / polymorphism but IMHO this is taking OOP too far - I'd rather have one big 40-way switch statement than 40 new classes to deal with.
- A complex function might have a lot of state variables that would get very messy if passed between different functions as parameters. In this case you could reasonably make an argument that the code is simpler and easier to follow if you keep everything in a single large function (although as Mark rightly points out this could also be a candidate for turning into a class to encapsulate both the logic and state)
- Sometimes smaller or larger functions have performance advantages (perhaps because of inlining or JIT reasons as Frank mentions). This is highly implementation dependent, but it can make a difference - make sure you benchmark!
So basically, use common sense, stick to small function sizes in most instances but don't be dogmatic about it if you have a genuinely good reason to make an unusually big function.
Taken from here.

- 1
- 1

- 608
- 4
- 9
It's impossible to say in the general case, but no, probably not.
For one thing: Method calls are really, really fast.
For another, the JVM monitors the work done by your code and when it sees a "hot spot" (a part of the code that gets run a lot), it aggressively optimizes that part of the code. One of the ways it does that is by inlining methods where possible — that is, by relocating the code from the method into the method that's calling it. At which point, the performance is the same as if you had put the code there yourself. So you get the maintenance and testability benefits of small methods, but the benefit of inlined code if it's useful to inline it.
Again, though, it cannot be answered in the general case. If you have a specific performance problem, benchmark to see whether it matters in that specific situation.

- 1
- 1

- 1,031,962
- 187
- 1,923
- 1,875
-
1Furthermore, the smaller and more cohesive your methods are, the more opportunity the JVM has auto-optimise. – slim Nov 10 '16 at 10:59