Использование 'var' будет влиять на производительность?
7 ответов
Нет никакого дополнительного кода IL для var ключевое слово: получающийся IL должен быть идентичным для неанонимных типов. Если компилятор не может создать это IL, потому что это не может выяснить то, что вводит Вас, намеревался использовать, Вы получите ошибку компилятора.
единственный прием - то, что var выведет точный тип, где Вы, возможно, выбрали Interface или родительский тип, если необходимо было установить тип вручную.
Обновление 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 переменная. Но сказать это никогда не имеет значение, вообще может преувеличивать его.
Как Joel говорит, компилятор разрабатывает в время компиляции , каков var типа должен быть, эффективно это - просто прием, который компилятор выполняет для сохранения нажатий клавиш, таким образом, например
var s = "hi";
заменяется
string s = "hi";
компилятором , прежде чем любой IL будет сгенерирован. Сгенерированный IL будет точно то же, как будто Вы ввели строку.
Компилятор C# выводит истинный тип var переменная во время компиляции. Нет никакого различия в сгенерированном IL.
Я не думаю, что Вы правильно поняли то, что Вы читаете. Если это компилируется в корректный тип, то там никакое различие. Когда я делаю это:
var i = 42;
компилятор знает , это - интервал, и генерируйте код, как будто я записал
int i = 42;
Как сообщение, с которым Вы связались, говорит, это добирается , скомпилировал в тот же тип. Это не проверка на этапе выполнения или что-либо еще требующее дополнительного кода. Компилятор просто выясняет то, чем тип должен быть, и использование это.
Нет никакой стоимости производительности во время выполнения для использования var. Хотя, я подозревал бы там, чтобы быть стоимостью выполнения компиляции, поскольку компилятор должен вывести тип, хотя это, скорее всего, будет незначительно.
Если компилятор может сделать автоматический вывод типа, то там привычка является любой проблемой с производительностью. Оба из них генерируют тот же код
var x = new ClassA();
ClassA x = new ClassA();
однако при построении типа динамично (LINQ...) тогда var единственный вопрос и существует другой механизм для сравнения с тем, для высказывания, что является штрафом.
Поскольку еще никто не упомянул отражатель .. .
Если вы скомпилируете следующий код C #:
static void Main(string[] args)
{
var x = "hello";
string y = "hello again!";
Console.WriteLine(x);
Console.WriteLine(y);
}
Затем примените к нему рефлектор, вы получите:
// Methods
private static void Main(string[] args)
{
string x = "hello";
string y = "hello again!";
Console.WriteLine(x);
Console.WriteLine(y);
}
Итак, ответ очевиден: производительность во время выполнения не снижается!