Блог

Заключается в следующем:

 MyObject myVariable;
for(int i = 0; i < objects.Length, i  ){
  myVariable = objects[i];
  // do stuff...
}
 

более эффективно, чем:

 for(int i = 0; i < objects.Length, i  ){
  MyObject myVariable = objects[i];
  // do stuff...
}
 

потому что новая переменная для хранения ссылки создается не каждый раз? (или разработчик достаточно умен, чтобы просто использовать одну и ту же переменную)..

(Если создается новая переменная, помещается ли она в кучу?)

Нет, «переменные» существуют почти полностью ради программиста. Вы не создаете никакой дополнительной работы во время выполнения, объявляя переменную внутри метода.

Теоретически компилятор выделит место в стеке при вызове метода для каждой переменной, объявленной в этом методе. Таким образом, наличие этой переменной в методе было бы более важным, чем его область применения. В куче не выделяется место, если new не используется ключевое слово.

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

 var a = b[c];
a.ToString();
// never access "a" again.
 

… было бы то же самое, что:

 b[c].ToString();
 

… потому что компилятор распознает, что ему нужно только сохранить результат b[c] достаточно долго, чтобы вызвать на нем метод, поэтому он может просто использовать регистр процессора вместо использования памяти.

По этой причине объявление переменной внутри цикла может фактически привести к тому, что метод выделит меньше места в стеке для переменной, в зависимости от возможного последующего логического потока. Однако это приводит к огромной микрооптимизации, которая не имеет никакого смысла для большинства людей.

Обновить

Поскольку некоторые люди все еще, кажется, думают, что объявление переменной в цикле имеет некоторый эффект, я думаю, мне нужно предоставить доказательства. Введите в LINQPad следующие программы.

 int j;
for(int i = 0; i < 5; i  )
{
    j = i;
}
 

… и…

 for(int i = 0; i < 5; i  )
{
    int j = i;
}
 

Выполните код, затем перейдите на вкладку IL, чтобы просмотреть сгенерированный код IL. Это одно и то же для обеих этих программ:

 IL_0000:  ldc.i4.0    
IL_0001:  stloc.0     
IL_0002:  br.s        IL_0008
IL_0004:  ldloc.0     
IL_0005:  ldc.i4.1    
IL_0006:  add         
IL_0007:  stloc.0     
IL_0008:  ldloc.0     
IL_0009:  ldc.i4.5    
IL_000A:  blt.s       IL_0004
 

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

Я оценил «Проблему» и согласился с Stripling Warrior. По крайней мере, это не имеет никакого значения с точки зрения скорости.

 long start = Time();
long end = Time();
Console.WriteLine("Benchmark Runtime: "   (end - start)   " Microseconds");

for(int k = 0; k < 5; k  )
{
    start = Time();
    int j;
    for (int i = 0; i < 900000000; i  )
    {
        j = i;
    }
    end = Time();
    Console.WriteLine("Benchmark 1: "   (end - start)   " Microseconds");
}

for (int k = 0; k < 5; k  )
{
    start = Time();
    for (int i = 0; i < 900000000; i  )
    {
        int j = i;
    }
    end = Time();
    Console.WriteLine("Benchmark 2: "   (end - start)   " Microseconds");
}
 

Результаты:

 Benchmark Runtime: 1 Microseconds
Benchmark 1: 1730816 Microseconds
Benchmark 1: 1725885 Microseconds
Benchmark 1: 1725629 Microseconds
Benchmark 1: 1726052 Microseconds
Benchmark 1: 1726121 Microseconds
Benchmark 2: 1725843 Microseconds
Benchmark 2: 1725576 Microseconds
Benchmark 2: 1726233 Microseconds
Benchmark 2: 1725786 Microseconds
Benchmark 2: 1729965 Microseconds
 

короткий ответ, да.

длинный ответ, да, это быстрее, но едва ли заметно, если не повторять много раз. 🙂

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