5

I am learning C# and .NET, and I frequently use the keyword var in my code. I got the idea from Eric Lippert and I like how it increases my code's maintainability.

I am wondering, though... much has been written in blogs about slow heap-located refs, yet I am not observing this myself. Is this actually slow? I am referring to slow compile times due to type inferencing.

Pops
  • 30,199
  • 37
  • 136
  • 151
PRASHANT P
  • 1,527
  • 1
  • 16
  • 28
  • Of course it is not. It is compiled in the same way as the type is known at compilation – Oskar Kjellin May 13 '11 at 17:59
  • Re the suggested duplicate above; I disagree - that question is explicitly about RUNTIME performance (IL); this question is specifically about COMPILER performance. The two are completely unrelated. – Marc Gravell May 13 '11 at 19:58

5 Answers5

23

You state:

I am referring to slow time for compile due to type 'inferencing'

This does not slow down the compiler. The compiler already has to know the result type of the expression, in order to check compatibility (direct or indirect) of the assignment. In some ways using this already-known type removes a few things (the potential to have to check for inheritance, interfaces and conversion operators, for example).

It also doesn't slow down the runtime; they are fully static compiled like regular c# variables (which they are).

In short... it doesn't.

RBT
  • 24,161
  • 21
  • 159
  • 240
Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
15

'var' in C# is not a VARIANT like you're used to in VB. var is simply syntactic sugar the compiler lets you use to shorthand the type. The compiler figures out the type of the right-hand side of the expression and sets your variable to that type. It has no performance impact at all - just the same as if you'd typed the full type expression:

var x = new X();

exactly the same as

X x = new X();

This seems like a trivial example, and it is. This really shines when the expression is much more complex or even 'unexpressable' (like anonymous types) and enumerables.

n8wrl
  • 19,439
  • 4
  • 63
  • 103
  • 2
    I was asked 'why use var at all' recently and I was very tempted to wave a finger at anonymous types. However, I believe a more practical example of usage is for the LINQ expressions that it was inserted to support - where the return type is quite hard to manually infer from the query. This may just be because I explaining to a C programmer (new to c#) whom anonymous types would have slayed. – Gusdor Mar 12 '12 at 16:17
7

Var is replaced at compile time with your actual variable type. Are you thinking of dynamic?

Mike M.
  • 12,343
  • 1
  • 24
  • 28
2

A "variant" is typeless, so access to state (or internal state conversion) always must go through two steps: (1) Determine the "real" internal type, and (2) Extract the relevant state from that "real" internal type.

You do not have that two-step process when you start with a typed object.

True, a "variant" thus has this additional overhead. The appropriate use is in those cases where you want the convenience of any-type for code simplicity, like is done with most scripting languages, or very high-level APIs. In those cases, the "variant" overhead is often not significant (since you are working at a high-level API anyway).

If you're talking about "var", though, then that is merely a convenience way for you to say, "Compiler, put the proper type here" because you don't want to do that work, and the compiler should be able to figure it out. In that case, "var" doesn't represent a (runtime) "variant", but rather a mere source-code specification syntax.

charley
  • 5,913
  • 1
  • 33
  • 58
2

The compiler infers from the constructor the type.

var myString = "123"; is no different from string myString = "123";

Also, generally speaking, reference types live on the heap and value types live on the stack, regardless if they're declared using var.

SquidScareMe
  • 3,108
  • 2
  • 24
  • 37
  • 1
    It would be clearer to say "return-type of the expression" rather than mentioning constructors, since constructors are just one tiny use-case here – Marc Gravell May 13 '11 at 18:32
  • thank you this is very much helpful i did not know all values on stack – PRASHANT P May 13 '11 at 18:35
  • @Marc - You're right. Thanks for clarifying. @Prashant - you're most welcome. I'm happy to have helped. – SquidScareMe May 13 '11 at 18:40
  • "All value types live on the stack" is not a factual statement. See (among other places): http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-truth-about-value-types.aspx – Anthony Pegram May 13 '11 at 19:33
  • @Anthony Pegram - Noted and updated post to reflect your comment. – SquidScareMe May 13 '11 at 19:51
  • 2
    I wouldn't even say "generally speaking" here. It's not like having an instance variable of type `int` in a class is unusual. Over-simplifications like this don't really help. – Jon Skeet Jan 14 '15 at 16:05
  • `value types live on the stack` - This understanding isn't that black and white. In fact, possibility of even local variable (which is a value type) to get stored on stack is actually very very low as stack is NOT the only memory area where local variables get stored. [Here](http://stackoverflow.com/questions/14022680/any-tool-to-see-where-variables-or-stored-while-net-program-getting-executed) is how. – RBT Feb 16 '17 at 01:24