In C you do not have overloads . Only in C ++ and C #.

This is the overload of methods or functions. Roughly it consists of having a function with the same name but with parameters of different types . I will not go into detail because you already have answer about the subject , it shows the inner workings.

Although the criteria for solving which method to use differ, C ++ works essentially the same way as C #, or Java, for example. Most modern statically typed languages have something like this.

This does not affect performance at all. On the contrary, one of the most commonly used alternatives (solve, probably with if or switch , what the method should actually do, since there are alternative execution paths) would affect the performance by delegating the decision to the execution time .

Another way would be to use different names for similar functions, like C does. What can affect readability, but not performance.

What the IDE shows is that you have alternatives to choose which subscription to use. In the specific case there are 4 different methods that can be applied there. If it has multiple parameters, as it puts new arguments in the call, it tapers and decreases, until it goes no further show this tip because you already have a unique signature and there is no confusion with others. You will always have to reduce the ambiguity to zero.

Practical example with 2 overload .

    

Why do overloads have no cost of performance?

Complementing the bigown response , the compiler or virtual machine is able to resolve the overloads statically, identifying only methods not only by name, but by name and parameter types. It is as if the methods metodo(String) , metodo(int) and metodo(String, int) were not called only metodo , but metodo_String , metodo_int and metodo_String_int , which means that each of them has a different identification . And because of that, there's no weight involved in performance in this regard.

And the overrides ?

As for overrides , the operation is different, the method called depends on the class of the instance, which is information that will only be present at runtime.

A simple way to implement an override would be for virtual methods (ie methods that can be overridden) to be implemented internally with a if or switch that looks at the type of this by calling the appropriate concrete method, which would have some reasonable weight in terms of performance. This is not how the override is implemented.

In fact, overrides are resolved through function pointers and vtables in> . Each vtable is a table that each concrete class has function pointers for the methods implemented in that class. So, when calling a method, what happens internally is that a reference to the class is obtained from the reference to the class that each instance has, and from that reference to the class (containing the start of vtable in a fixed memory offset), the function pointer referring to the method to be invoked is obtained, being passed the reference to the instance as a parameter, along with the other parameters. And before anyone asks, yes, that means that the compiler or virtual machine adds a hidden parameter that becomes the this ference in each non-static method.

Regarding performance, there is a minimal cost associated with invoking non-static methods, which consists of an indirection operation and a sum of integers, and is done by dereferencing the pointer to the instance, reading an integer of the memory location obtained (which is the address of the class, which will always be the first available information in the memory area allocated to each object) and add to that address the offset of the method within vtable , thus obtaining the pointer to the corresponding method. This contrasts with the case of static methods, in which the pointer to the method is already known in advance. References to interface methods may need one or two machine instructions to resolve, as the method's location in vtable will be a bit more complicated.

On the other hand, people who design compilers and virtual machines try to optimize this performance cost, so that virtual methods calls that can be determined statically (for example, when the instance type is a concrete class for which it does not there are subclasses) can be simplified by eliminating the need to fetch the method at runtime by doing this at compile time, also eliminating the associated cost. In addition, other types of more complex optimizations with just-in-time compilation are possible to eliminate these costs in a number of cases.