Method Overloading Cost In .Net

Is there a cost associated with overloading methods in .Net?

So if I have 3 methods like:

Calculate (int)
Calculate (float)
Calculate (double)

and these methods are called at runtime "dynamically" based on what's passed to the Calculate method, what would be the cost of this overload resolution?

Alternatively I could have a single Calculate and make the difference in the method body, but I thought that would require the method to evaluate the type every time it's called.

Are there better ways/designs to solves this with maybe no overhead? Or better yet, what's the best practice to handle cases like these? I want to have the same class/method name, but different behaviour.

EDIT: Thanks all. Jusdt one thing if it's any different. I was wondering say you have a DLL for these methods and a program written in C# that allows the user to add these methods as UI items (without specifying the type). So the user adds UI item Calculate (5), and then Calculate (12.5), etc, and the C# app executes this, would there still be no overhead?

From stackoverflow

• 3 different methods are produced in IL based on the type. The only cost will be if you are casting from one type to another, but that cost won't be significant unless you have a large amount to do. So you could stick to Calculate(double) and cast from there.

• As far as the runtime is concerned these are different methods. Is the same as writing:

  CalculateInt(int)
  CalculateFloat(float)
  

  Regarding the performance issues, except very special cases, you can safely ignore the method call overhead.

  John Baughman : One way to optimize this would be to use generics.

  Joan Venge : @John: you mean for my 3 Calculate method case?

  Chris Lively : @Aleris: What kind of special cases?

  Aleris : @Chris: For example http://www.codeplex.com/FarseerPhysics uses 'inline' methods for vector math (the code is duplicated as would a macro do in C).

  Michael Meadows : If the level of optimization requires inlining methods, it's time to move to C++. :)

• First, unless your profiler is telling you there's a performance problem, you shouldn't sacrifice good design for assumed performance gains.

  To answer your question, the resolution of method calls isn't dynamic. It's determined at compile time, so there's no cost in that respect. The only cost would be in the potential implicit casting of a type to fit the parameter type.

• This question is about method overloading, not polymorphism. As far as I know, there isn't a penalty for method overloading, since the compiler will figure out which method to call at compile time based on the type of the argument being pass to it.

  Polymorphism only comes into play where you are using a derived type as a substitute for a base class.

  C. Ross : Thank you for pointing out the obvious (not sarcastic, I upvoted). There is a significant difference between overloading and Polymorphism.

• The method overload (i.e. the method table slot) is not resolved dynamically at runtime, it is resolved statically at compile time, so there is zero cost in having overloaded methods.

  I assume you're thinking of virtual methods where the actual implementation may be overridden by a derived type and the actual method picked based on the concrete type. But that has nothing to do with overloading as virtual methods occupy the same method table slot.

• There is no "cost" at run time because the compiler determines which method to call at compile time. The IL that is generated specifically calls the method that takes the appropriate parameters.

  Take this for example"

  public class Calculator
  {
      public void Calculate(int value)
      {
          //Do Something
      }
      public void Calculate(decimal value)
      {
          //Do Something
      }
      public void Calculate(double value)
      {
          //Do Something
      }
  }
  
  static void Main(string[] args)
  {
      int i = 0;
      Calculator calculator = new Calculator();
      calculator.Calculate(i);
  }
  

  The following call is made in IL to calculate the variable "i":

  L_000b: callvirt instance void ConsoleApplication1.Calculator::Calculate(int32)
  

  Notice that it specifies the method is of type int32 which is the same type as the variable passed in from the Main method.

  So if there is a cost at all it's only at compile time. No worries.

  As JaredPar noted below:

  There is a misconception in your question. Overloaded methods in C# are not called dynamically at runtime. All method calls are bound statically at compile time. Hence there is no "searching" for a method at runtime, it's predetermined at compile time which overload will be called.

• There is a misconception in your question. Overloaded methods in C# are not called dynamically at runtime. All method calls are bound statically at compile time. Hence there is no "searching" for a method at runtime, it's predetermined at compile time which overload will be called.

  Note: This changes a bit with C# 4.0 and dynamic. With a dynamic object it is possible that an overload will be chosen at runtime based on the type of the object. This is not the case with C# 3.0 and below though.