Why is casting faster then reflection in .NET?

Question

I have an event handler that needs to determine a type and execute code if it matches a specific type. Originally we cast it to an object and if it wasn't null we executed the code, to speed it up I used reflection and it actually slowed it down and I don't understand why.

here is a code sample

Trace.Write("Starting using Reflection");
if (e.Item.GetType() == typeof(GridDataItem))
{
      bool isWatch = Convert.ToBoolean(e.Item.OwnerTableView.DataKeyValues[e.Item.ItemIndex]["IsWatch"]);
      if (isWatch)
      {
          e.Item.Style["Font-Weight"] = "bold";
      }
 }
 Trace.Write("Ending using Reflection");
 Trace.Write("Starting using Cast");
 GridDataItem gridItem = e.Item as GridDataItem;
 if (gridItem !=null)
 {
     bool isWatch = Convert.ToBoolean(gridItem.OwnerTableView.DataKeyValues[e.Item.ItemIndex]["IsWatch"]);
     if (isWatch)
     {
         gridItem.Style["Font-Weight"] = "bold";
     }
  }
  Trace.Write("Ending using Cast");

And this is the trace output I get

Starting using Reflection  0.79137944962406 0.576538
Ending using Reflection    0.791600842105263    0.000221
Starting using Cast    0.791623353383459 0.000023
Ending using Cast      0.791649308270677 0.000026
Starting using Reflection  0.876253801503759    0.084604
Ending using Reflection    0.87631790075188 0.000064
Starting using Cast    0.87633445112782 0.000017
Ending using Cast      0.87634950075188 0.000015

it's not a lot, but if we had to do this a lot over time it could add up.

Answer 1

Reflection is slow because you are querying the assembly's metadata whereas casting simply changes the type of the object you are referencing.

The assembly's metadata is a useful store of information but that information is best used at compilation time rather than at execution time. That metadata is used by the compiler for static type checking (among other things). You are using that same metadata to look up type information at execution time (which is fine if you have no other choice) which is significantly slower than casting.

Answer 2

Reflection has to go at runtime and determine what properties etc. the object has at runtime. Casting tells the application that it should expect that an object has X properties and should function in a certain way.

Answer 3

Casting tells the runtime you "know" the type of a particular object. While you may possibly be wrong the runtime believes you and doesn't take the extra time needed to go check the assembly's meta data.

Answer 4

Why aren't you using the is operator? I think it's more readable as you don't have the explicit cast, then check. It simply checks that the variable is of the correct type.

if (e.Item is GridDataItem)
{
    bool isWatch = Convert.ToBoolean(e.Item.OwnerTableView.DataKeyValues[e.Item.ItemIndex]["IsWatch"]);
    if (isWatch)
    {
        e.Item.Style["Font-Weight"] = "bold";
    }
}

Answer 5

Well i giess a short answer to the best practice part would be never use reflection if you can get the same result with regular code.

When optimizing code it's usually a good Idea to estimate where the time spent optimizing will result in the greatest performance gain. reimplementing operators natively in the language is seldom going to be on the top of that list

Answer 6

Casts can be done as integer comparisons within the runtime but reflection involves full method calls.