Is method overload less performative?

Does not affect performance, because the method that will be invoked can be determined at compile time.

Perhaps the author of the commentary was referring to avoiding overloading because it may make readability worse.

    

No. Performance should be the same. The method to be called is decided at compile time, based on the types of arguments, since these are already known at the moment. You can imagine that each method with the same name is translated to a method with a unique name in bytecode , and each call to them is replaced by a call to the corresponding method. You can see that you do not have to stop the call to check tables or something.

Note that this is different from overriding . In this case, you must decide at runtime which method should be called (as specific as possible, in this case). This is done by looking at virtual call tables, which adds a cost.

In any case, as with performance talk, the best thing to do is to worry about writing the clearest and cleanest code possible, avoiding premature optimizations . If after performance is poor, you should take steps to identify where the "bottleneck" of your application is. Usually not in that kind of detail.

    

The overhead itself does not affect performance because they are methods like any other, they do not have anything special other than the fact that there is the same name, but all of this is decided at compile time not generating execution cost.

It may slightly increase compilation time, but it's whimsy.

What may occur is that it is normal in cases like this an overloaded method to call another overload by passing some extra argument or doing a preparation before or treating the result afterwards. In this case there may be a small overhead of calling a new method. But it may also be because the compiler and the JITter are clever enough to optimize this if it's worth it and is possible.

Anyway the alternative would be to duplicate code that is bad for maintenance, eventually violating the DRY . .

Do not be afraid to use overhead where it makes sense. Just do not use if the methods do different things. Overloading should be used when the same action will be performed with different input data.

It could be that the commentary referred to something else. If you had access to the code to see the context it would give you a better answer.

    

On performance in method calls in Java, I would first say not to worry so strongly about the subject, to let worry when performance is a real bottleneck. Secondly, I would say that your algorithm is wrong. But it also does not cost anything to know the JVM operation, right?

When you compile a Java code, it generates JVM bytecodes. When there is a method / function call, the compiler puts a method invocation bytecode. I quickly remember the following invocations:

• invokeStatic : for static methods; binding is done at the compilation level, not needing to do a very large search;
• invokeSpecial : for constructors and private methods; also decided on compilation;
• invokeVirtual : for class method calls, used to make the polymorphism; you can only do the binding at runlevel, so the JVM does a search in the class table of methods, which implies a little more time;
• invokeInterface : for method calls from an interface; similar to invokeVirtual , can only be determined at execution level.

Examples of when invocations occur

public interface Suricate {
  int seboso();
}

public class Marmota implements Suricate {
  @Override
  public int seboso() {
    return 1;
  }

  @Override
  public String toString() {
    return "marmota";
  }

  public Marmota() {
    System.out.println(seboso() + prvt() + sttc());
  }

   private int prvt() {
     return 4;
  }

  static int sttc() {
    return 5;
  }

  public int somaSeboso(Suricate s) {
    return seboso() + s.seboso();
  }
}

When calling new Marmota() , there is a invokeSpecial calling the constructor.

Within the constructor, there is the call to 3 methods within the class: "

• seboso() , called with invokeVirtual
• prvt() , called with invokeSpecial
• sttc() , called with invokeStatic

When calling somaSeboso , there are two method calls:

• seboso() , which is the same as this.seboso() , called with invokeVirtual
• s.seboso() , which is called through invokeInterface

The invocation speed in terms of speed is (faster first):

• invokeStatic
• invokeSpecial
• invokeVirtual
• invokeInterface

  

I do not remember if it has any relation between invokeStatic and invokeSpecial

     

I also do not know how invokeDynamics of Java 7 fits in this relationship

     

JITter can also positively affect performance

This is just a general reminder of how to execute method invocation, so do not try to force a method that should of course be called via invokeVirtual to be called as invokeSpecial . It's not very positive you force levels of abstraction distinct from those that are natural to your program.