I always thought DirectCast() was fairly inexpensive, perforance- and memory-wise, and saw it basically as a way of helping me with IntelliSense, e.g. in event handlers:
Public Sub myObject_EventHandler(sender As Object, e As System.EventArgs)
'Explicit casting with DirectCast
Dim myObject As myClass = DirectCast(sender, myClass)
myObject.MyProperty = "myValue"
End Sub
I figured this was better, obviously, for me as a developer, but also for the compiled code and resulting performance, because it enabled "early binding" as opposed to ...
Public Sub myObject_EventHandler(sender As Object, e As System.EventArgs)
'No casting at all (late binding)
myObject.MyProperty = "myValue"
End Sub
... which compiles and runs also, but uses "late binding", if I got the terms correctly. i.e. assuming that sender is in fact a myClass object.
In regards to performance, late/early binding, or anything else, what are the differences between the very first snippet above and the following one :
Public Sub myObject_EventHandler(sender As Object, e As System.EventArgs)
'Implicit casting via variable declaration
Dim myObject As myClass = sender
myObject.MyProperty = "myValue"
End Sub
Is the explicit DirectCast() call useful/harmful or does it make no difference after the compiler has optimized the code?
TL;DR version: Use
DirectCast()instead of late binding or reflection for better runtime performance.This question was very intriguing to me. I use
DirectCast()on a very regular basis for nearly every application that I've written. I've always used it because it makes IntelliSense work and if I don't withOption Strict Onthen I'll get errors when compiling. Every once in a while I useOption Strict Offif I'm in a hurry and I'm testing a design concept or if I'm in a hurry for a quick and dirty solution to a one-off problem. I've never given a second thought to performance effects in using it because I've never had to be concerned with runtime performance with the things I write.Thinking about this question made me a little curious so I decided I'd test it out and see the differences for myself. I created a new Console application in Visual Studio and went to work. Below is the entire source code for the application. If you want to see the results for yourself you should be able to just copy/paste directly:
I tried running the application in
Releaseconfiguration as well as running the release config without the Visual Studio debugger attached. Here are the outputted results:Release with Visual Studio Debugger:
Release without Visual Studio Debugger:
Looking at those results it would look as though using
DirectCast()has almost no performance hit compared to the compiler adding in the casting. However when relying on the object to be late bound there is a HUGE performance hit and the execution slows down considerably. When usingSystem.Reflection, there is a slight slowdown over casting the object directly. I thought it was unusual that getting thePropertyInfowas so much faster than using the.InvokeMember()method.Conclusion: Whenever possible use
DirectCast()or cast the object directly. Using reflection should be reserved for only when you need it. Only use late bound items as a last resort. Truthfully though, if you're only modifying an object a few times here or there it's likely not going to matter in the grand scheme of things.Instead you should be more concerned about how those methods could fail and how to keep them from doing so. For example, in the
SetObjectInvokeMember()method, if thesenderobject didn't have theMyPropertyproperty, then that bit of code would have thrown an exception. In theSetObjectReflection()method, the returned property info could have beennothingwhich would have resulted in aNullReferenceException.