Для ключевого слова var
нет дополнительного кода IL: результирующий IL должен быть идентичным для неанонимных типов. Если компилятор не может создать этот IL, потому что он не может определить, какой тип вы намеревались использовать, вы получите ошибку компилятора.
Единственная хитрость в том, что var
выведет точный тип, если вы, возможно, выбрали интерфейс или родительский тип, если бы вам пришлось установить тип вручную.
Обновление 8 лет спустя
Мне нужно обновить это, так как мое понимание изменилось. Теперь я верю, что var
может повлиять на производительность в ситуации, когда метод возвращает интерфейс, но вы бы использовали точный тип. Например, если у вас есть этот метод:
IList<int> Foo()
{
return Enumerable.Range(0,10).ToList();
}
Рассмотрим эти три строки кода для вызова метода:
List<int> bar1 = Foo();
IList<int> bar = Foo();
var bar3 = Foo();
Все три компилируются и выполняются, как и ожидалось. Однако первые две строки не абсолютно одинаковы, а третья строка будет соответствовать второй, а не первой. Поскольку подпись Foo()
должна возвращать IList<int>
, именно так компилятор будет создавать переменную bar3
.
С точки зрения производительности, в большинстве случаев вы этого не заметите. Однако существуют ситуации, когда производительность третьей строки может быть не такой быстрой, как производительность первой . Поскольку вы продолжаете использовать переменную bar3
, компилятор может не иметь возможности отправлять вызовы методов одинаково.
Обратите внимание, что возможно (вероятно, даже) дрожание сможет стереть эту разницу, но это не гарантируется. Как правило, вы все равно должны рассматривать var
как фактор, не влияющий на производительность. Это совсем не то же самое, что использование переменной dynamic
. Но сказать, что это никогда не имеет значения, может быть преувеличивать.