Влияет ли инициализация локальной переменной с нулевым значением на производительность? - PullRequest
Новая
       25

Влияет ли инициализация локальной переменной с нулевым значением на производительность?

7 голосов
/ 20 января 2011

Давайте сравним две части кода: 

String str = null;
//Possibly do something...
str = "Test";
Console.WriteLine(str);

и 

String str;
//Possibly do something...
str = "Test";
Console.WriteLine(str);

Я всегда думал, что эти части кода равны. Но после того, как я собрал этот код (режим выпуска с проверкой оптимизации) и сравнил сгенерированные методы IL, я заметил, что в первом примере есть еще две инструкции IL:

1-й пример кода IL:

.maxstack 1
.locals init ([0] строка str)
IL_0000: ldnull
IL_0001: stloc.0
IL_0002: ldstr "Тест"
IL_0007: stloc.0
IL_0008: ldloc.0
IL_0009: вызов void [mscorlib] System.Console :: WriteLine (строка)
IL_000e: рет

2-й пример кода IL:

.maxstack 1
.locals init ([0] строка str)
IL_0000: ldstr "Тест"
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: вызов void [mscorlib] System.Console :: WriteLine (строка)
IL_000c: рет

Возможно, этот код оптимизирован JIT-компилятором? Так как инициализация локальной переменной bethod со значением null влияет на производительность (я понимаю, что это очень простая операция, но в любом случае), и мы должны избегать этого? Заранее спасибо.

Ответы [ 3 ]

7 голосов
/ 20 января 2011

http://www.codinghorror.com/blog/2005/07/for-best-results-dont-initialize-variables.html

Подводя итог, можно сказать, что после выполнения различных тестов инициализация объекта значением (либо как часть определения, в конструкторе класса, либо как часть метода инициализации) может составлять примерно 10-35. % медленнее в .NET 1.1 и 2.0. Новые компиляторы могут оптимизировать инициализацию по определению. Статья заканчивается рекомендацией избегать инициализации как общего правила.

6 голосов
/ 21 января 2011

Это немного медленнее, как указывает ссылка Jon.Stromer.Galley. Но разница удивительно мала; скорее всего, порядка наносекунд . На этом уровне издержки от использования языка высокого уровня, такого как C #, затмевают любую разницу в производительности. Если производительность является такой большой проблемой, вы также можете программировать на C или ASM или что-то в этом роде.

Ценность написания понятного кода (что бы это ни значило для вас) намного перевесит увеличение производительности на 0,00001 мс с точки зрения затрат и выгод. Вот почему C # и другие языки высокого уровня существуют в первую очередь.

Я понимаю, что это, вероятно, подразумевается как академический вопрос, и я не сбрасываю со счетов ценность понимания внутренних органов CLR. Но в этом случае просто кажется неправильным сосредоточиться.

0 голосов
/ 12 июля 2019

Сегодня (2019) и .NET Framework, и компиляторы .NET Core достаточно умны, чтобы оптимизировать ненужные инициализации на расстоянии .(Вместе с бесполезной парой stloc.0 - ldloc.0.)

Обе версии компилируются как 

        .maxstack 8

        ldstr "Test"
        call void [System.Console]System.Console::WriteLine(string)
        ret

См. Мой эксперимент SharpLab в качестве справочного.

Но, конечно, реализации меняются, но ответ Джастина вне времени: я провел этот эксперимент из любопытства, в реальной ситуации сосредоточился на ясности и выразительности кода и игнорировал микрооптимизации.

...