Using GetCurrentMethod in (supposedly) high-performance code

Question

For logging purposes, some methods in our application include the following line:

Dim Log As ILog = GetLog(Reflection.MethodBase.GetCurrentMethod().DeclaringType)

I have what might be described as an irrational fear of reflection, which I try to keep in check. However, calls like this in methods that are executed potentially a hundred times a second concern me. I don't know as much as I should about reflection; but from looking briefly over the documentation, it looks to me like I could replace the following with:

Dim Log As ILog = GetLog(Me.GetType())

My question is three-fold:

1. Does Me.GetType() actually return the same Type as GetCurrentMethod().DeclaringType?
2. Does Me.GetType() actually do anything differently from GetCurrentMethod().DeclaringType, or is it doing the same thing under the hood?
3. Should I not even be worried about this at all? Performance is critical in this application; the program runs fine, but the nature of our business is such that if we can shave off even a few microseconds here and there, that is useful.

Answer 1

Does Me.GetType() return the as GetCurrentMethod().DeclaringType?

It depends. Me.GetType will always return the actual type of an object. GetCurrentMethod().DeclaringType will return the type in which the method was declared. These values can be different in inheritance scenarios.

Consider the following

Class C1
  Public Sub Foo() 
    ..
  End Sub
End Class
Class C2 
  Inherits C1
  ..
End Class

Inside method Foo the two expressions would be equal if you were dealing with an instance of C1. But if it was C2 they would be different.

Does Me.GetType() do anything differently from GetCurrentMethod().DeclaringType

Yes these are very different functions. Me.GetType determines the runtime type of the current instance of the class. GetCurrentMethod.DeclaringType determines in what type was this method declared.

Should I not even be worried about this at all?

If this is a performance critical scenario then yes you make sure you profile APIs you do not understand. Especially those that appear to involve reflection. But only a profiler will tell you which is definitively faster. My money is on Me.GetType though.

Answer 2

In your situation this.GetType() will yield the same result as MethodBase.GetCurrentMethod().DeclaringType does. See JaredPar's answer for a situation where both calls will return different types.

In the general case the type exposing a member (obtained via the MemberInfo.ReflectedType property) and the type declaring a member (obtained via the MemberInfo.DeclaringType property) may differ.

UPDATE

I just profiled it using C# - this.GetType() required 2.5 ns per call while MethodBase.GetCurrentMethod().DeclaringType required 2490 ns per call - so you have a speed up of about factor 1200.

[Intel Core 2 6400 2.13 GHz | 3.5 GiB | WinXP Pro SP2 | .NET FX 3.5 SP1 | Release | Without Debugger]

Answer 3

I just had the same question and found this answer, but maybe it is not up to date any more so I post my testresults...

I don't know about previous versions of the dot net Framework, but in dot net Framework 4 I get the following calling Times. So performance should not be an issue any more...

• First Call to MethodBase.GetCurrentMethod().DeclaringType: 0 ms - 221 ticks
• First Call to this.GetType(): 0 ms - 225 ticks

Here is the code which produced this output:

        _txtReport.Text = string.Empty;
        var sw = new Stopwatch();

        sw.Start();
        var type = MethodBase.GetCurrentMethod().DeclaringType;
        sw.Stop();

        _txtReport.Text += string.Format("First Call to MethodBase.GetCurrentMethod().DeclaringType: {0} ms - {1} ticks{2}",
                                         sw.ElapsedMilliseconds, sw.ElapsedTicks, Environment.NewLine);

        sw.Start();
        var type1 = this.GetType();
        sw.Stop();

        _txtReport.Text += string.Format("First Call to this.GetType(): {0} ms - {1} ticks{2}",
                                         sw.ElapsedMilliseconds, sw.ElapsedTicks, Environment.NewLine);