Earlier I asked a question about why I see so many examples use the var
keyword and got the answer that while it is only necessary for anonymous types, that it is used nonetheless to make writing code 'quicker'/easier and 'just because'.
Following this link ("C# 3.0 - Var Isn't Objec") I saw that var
gets compiled down to the correct type in the IL (you will see it about midway down article).
My question is how much more, if any, IL code does using the var
keyword take, and would it be even close to having a measurable level on the performance of the code if it was used everywhere?
There's no extra IL code for the
var
keyword: the resulting IL should be identical for non-anonymous types. If the compiler can't create that IL because it can't figure out what type you intended to use, you'll get a compiler error.The only trick is that
var
will infer an exact type where you may have chosen an Interface or parent type if you were to set the type manually.Update 8 Years Later
I need to update this as my understanding has changed. I now believe it may be possible for
var
to affect performance in the situation where a method returns an interface, but you would have used an exact type. For example, if you have this method:Consider these three lines of code to call the method:
All three compile and execute as expected. However, the first two lines are not exactly the same, and the third line will match the second, rather than the first. Because the signature of
Foo()
is to return anIList<int>
, that is how the compiler will build thebar3
variable.From a performance standpoint, mostly you won't notice. However, there are situations where the performance of the third line may not be quite as fast as the performance of the first. As you continue to use the
bar3
variable, the compiler may not be able to dispatch method calls the same way.Note that it's possible (likely even) the jitter will be able to erase this difference, but it's not guaranteed. Generally, you should still consider
var
to be a non-factor in terms of performance. It's certainly not at all like using adynamic
variable. But to say it never makes a difference at all may be overstating it.The C# compiler infers the true type of the
var
variable at compile time. There's no difference in the generated IL.If the compiler can do automatic type inferencing, then there wont be any issue with performance. Both of these will generate same code
however, if you are constructing the type dynamically (LINQ ...) then
var
is your only question and there is other mechanism to compare to in order to say what is the penalty.I don't think you properly understood what you read. If it gets compiled to the correct type, then there is no difference. When I do this:
The compiler knows it's an int, and generate code as if I had written
As the post you linked to says, it gets compiled to the same type. It's not a runtime check or anything else requiring extra code. The compiler just figures out what the type must be, and uses that.
So, to be clear, it's a lazy coding style. I prefer native types, given the choice; I'll take that extra bit of "noise" to ensure I'm writing and reading exactly what I think I am at code/debug time. * shrug *
As Joel says, the compiler works out at compile-time what type var should be, effectively it's just a trick the compiler performs to save keystrokes, so for example
gets replaced by
by the compiler before any IL is generated. The Generated IL will be exactly the same as if you'd typed string.