Разница между объявлением переменных до или в цикле?

Что лучше: a или b?

С точки зрения производительности вам придется ее измерить. (И, на мой взгляд, если вы можете измерить разницу, компилятор не очень хорош).

С точки зрения обслуживания лучше b. Объявляйте и инициализируйте переменные в одном месте в максимально узкой области. Не оставляйте пустых промежутков между объявлением и инициализацией и не загрязняйте пространства имен, которые вам не нужны.

Что ж, я запускал ваши примеры A и B по 20 раз, зацикливался 100 миллионов раз (JVM - 1.5.0).

A: среднее время выполнения: 0,074 секунды

B: среднее время выполнения: 0,067 сек.

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

Это зависит от языка и конкретного использования. Например, в C # 1 это не имело значения. В C # 2, если локальная переменная захватывается анонимным методом (или лямбда-выражением в C # 3), это может иметь очень существенное значение.

Пример:

using System;
using System.Collections.Generic;

class Test
{
    static void Main()
    {
        List<Action> actions = new List<Action>();

        int outer;
        for (int i=0; i < 10; i++)
        {
            outer = i;
            int inner = i;
            actions.Add(() => Console.WriteLine("Inner={0}, Outer={1}", inner, outer));
        }

        foreach (Action action in actions)
        {
            action();
        }
    }
}

Выход:

Inner=0, Outer=9
Inner=1, Outer=9
Inner=2, Outer=9
Inner=3, Outer=9
Inner=4, Outer=9
Inner=5, Outer=9
Inner=6, Outer=9
Inner=7, Outer=9
Inner=8, Outer=9
Inner=9, Outer=9

Разница в том, что все действия захватывают одну и ту же outer переменную, но у каждого есть своя собственная переменная inner.

Ниже приводится то, что я написал и скомпилировал в .NET.

double r0;
for (int i = 0; i < 1000; i++) {
    r0 = i*i;
    Console.WriteLine(r0);
}

for (int j = 0; j < 1000; j++) {
    double r1 = j*j;
    Console.WriteLine(r1);
}

Это то, что я получаю от .NET Reflector, когда CIL отображается обратно в код.

for (int i = 0; i < 0x3e8; i++)
{
    double r0 = i * i;
    Console.WriteLine(r0);
}
for (int j = 0; j < 0x3e8; j++)
{
    double r1 = j * j;
    Console.WriteLine(r1);
}

Таким образом, после компиляции оба выглядят одинаково. В управляемых языках код преобразуется в CL / байтовый код, а во время выполнения он преобразуется в машинный язык. Таким образом, на машинном языке дубль даже не может быть создан в стеке. Это может быть просто регистр, поскольку код показывает, что это временная переменная для функции WriteLine. Только для циклов существует целый набор правил оптимизации. Так что обычному парню не стоит беспокоиться об этом, особенно если речь идет о управляемых языках. Бывают случаи, когда вы можете оптимизировать управляющий код, например, если вам нужно объединить большое количество строк, используя только string a; a+=anotherstring[i], а не StringBuilder. Между ними очень большая разница в производительности. Есть много таких случаев, когда компилятор не может оптимизировать ваш код, потому что он не может понять, что предполагается в более широком масштабе. Но он может в значительной степени оптимизировать для вас базовые вещи.

Это ошибка VB.NET. Результат Visual Basic не будет повторно инициализировать переменную в этом примере:

For i as Integer = 1 to 100
    Dim j as Integer
    Console.WriteLine(j)
    j = i
Next

' Output: 0 1 2 3 4...

Это напечатает 0 в первый раз (переменные Visual Basic имеют значения по умолчанию при объявлении!), Но i каждый раз после этого.

Однако если вы добавите = 0, вы получите то, что и ожидали:

For i as Integer = 1 to 100
    Dim j as Integer = 0
    Console.WriteLine(j)
    j = i
Next

'Output: 0 0 0 0 0...

Провел простой тест:

int b;
for (int i = 0; i < 10; i++) {
    b = i;
}

vs

for (int i = 0; i < 10; i++) {
    int b = i;
}

Я скомпилировал эти коды с помощью gcc - 5.2.0. Затем я разобрал main () из этих двух кодов и вот результат:

1º:

   0x00000000004004b6 <+0>:     push   rbp
   0x00000000004004b7 <+1>:     mov    rbp,rsp
   0x00000000004004ba <+4>:     mov    DWORD PTR [rbp-0x4],0x0
   0x00000000004004c1 <+11>:    jmp    0x4004cd <main+23>
   0x00000000004004c3 <+13>:    mov    eax,DWORD PTR [rbp-0x4]
   0x00000000004004c6 <+16>:    mov    DWORD PTR [rbp-0x8],eax
   0x00000000004004c9 <+19>:    add    DWORD PTR [rbp-0x4],0x1
   0x00000000004004cd <+23>:    cmp    DWORD PTR [rbp-0x4],0x9
   0x00000000004004d1 <+27>:    jle    0x4004c3 <main+13>
   0x00000000004004d3 <+29>:    mov    eax,0x0
   0x00000000004004d8 <+34>:    pop    rbp
   0x00000000004004d9 <+35>:    ret

vs

2º

   0x00000000004004b6 <+0>: push   rbp
   0x00000000004004b7 <+1>: mov    rbp,rsp
   0x00000000004004ba <+4>: mov    DWORD PTR [rbp-0x4],0x0
   0x00000000004004c1 <+11>:    jmp    0x4004cd <main+23>
   0x00000000004004c3 <+13>:    mov    eax,DWORD PTR [rbp-0x4]
   0x00000000004004c6 <+16>:    mov    DWORD PTR [rbp-0x8],eax
   0x00000000004004c9 <+19>:    add    DWORD PTR [rbp-0x4],0x1
   0x00000000004004cd <+23>:    cmp    DWORD PTR [rbp-0x4],0x9
   0x00000000004004d1 <+27>:    jle    0x4004c3 <main+13>
   0x00000000004004d3 <+29>:    mov    eax,0x0
   0x00000000004004d8 <+34>:    pop    rbp
   0x00000000004004d9 <+35>:    ret 

Которые точно такие же, как и результат. Разве это не доказательство того, что два кода производят одно и то же?

Это зависит от языка - IIRC C # оптимизирует это, поэтому нет никакой разницы, но JavaScript (например) будет выполнять все операции выделения памяти каждый раз.

Я бы всегда использовал A (вместо того, чтобы полагаться на компилятор), а также мог бы переписать так:

for(int i=0, double intermediateResult=0; i<1000; i++){
    intermediateResult = i;
    System.out.println(intermediateResult);
}

Это по-прежнему ограничивает intermediateResult областью цикла, но не объявляется повторно во время каждой итерации.

На мой взгляд, структура b лучше. В a последнее значение intermediateResult остается после завершения цикла.

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

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

Как правило, я объявляю свои переменные в самой внутренней возможной области. Итак, если вы не используете промежуточный результат вне цикла, я бы выбрал B.

Сотрудник предпочитает первую форму, говоря, что это оптимизация, и предпочитает повторно использовать объявление.

Я предпочитаю второй (и пытаюсь уговорить коллегу! ;-)), прочитав это:

• Это сокращает объем переменных до того места, где они необходимы, и это хорошо.
• Java достаточно оптимизируется, чтобы не оказывать существенного влияния на производительность. IIRC, возможно, вторая форма еще быстрее.

В любом случае, он попадает в категорию преждевременной оптимизации, которая зависит от качества компилятора и / или JVM.

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

Учитывая, что они в основном одинаковы: обратите внимание, что версия b делает гораздо более очевидным для читателей, что переменная не может и не может использоваться после цикла. Кроме того, версию b гораздо легче реорганизовать. В версии a сложнее извлечь тело цикла в собственный метод. Более того, версия b гарантирует, что у такого рефакторинга нет побочных эффектов.

Следовательно, версия a меня до бесконечности раздражает, потому что она бесполезна и значительно усложняет рассуждение о коде ...

Что ж, вы всегда можете найти место для этого:

{ //Or if(true) if the language doesn't support making scopes like this
    double intermediateResult;
    for (int i=0; i<1000; i++) {
        intermediateResult = i;
        System.out.println(intermediateResult);
    }
}

Таким образом, вы объявляете переменную только один раз, и она умрет, когда вы выйдете из цикла.

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

Я всегда думал, что если вы объявляете свои переменные внутри цикла, вы тратите память. Если у вас что-то вроде этого:

for(;;) {
  Object o = new Object();
}

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

Однако, если у вас есть это:

Object o;
for(;;) {
  o = new Object();
}

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

Моя практика следующая:

• если тип переменной простой (int, double, ...) Я предпочитаю вариант b (внутри).
  Причина: сокращение объем переменной.

• если тип переменной не простой (какой-то class или struct) я предпочитаю вариант a (внешний).
  Причина: сокращение количество звонков ctor-dtor.

У меня долгое время был один и тот же вопрос. Итак, я протестировал еще более простой фрагмент кода.

Вывод: для таких случаев разницы в производительности НЕТ.

Корпус с внешней петлей

int intermediateResult;
for(int i=0; i < 1000; i++){
    intermediateResult = i+2;
    System.out.println(intermediateResult);
}

Корпус с внутренней петлей

for(int i=0; i < 1000; i++){
    int intermediateResult = i+2;
    System.out.println(intermediateResult);
}

Я проверил скомпилированный файл в декомпиляторе IntelliJ и в обоих случаях получил то же самое Test.class

for(int i = 0; i < 1000; ++i) {
    int intermediateResult = i + 2;
    System.out.println(intermediateResult);
}

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

Корпус с внешней петлей

Code:
  stack=2, locals=3, args_size=1
     0: iconst_0
     1: istore_2
     2: iload_2
     3: sipush        1000
     6: if_icmpge     26
     9: iload_2
    10: iconst_2
    11: iadd
    12: istore_1
    13: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
    16: iload_1
    17: invokevirtual #3                  // Method java/io/PrintStream.println:(I)V
    20: iinc          2, 1
    23: goto          2
    26: return
LocalVariableTable:
        Start  Length  Slot  Name   Signature
           13      13     1 intermediateResult   I
            2      24     2     i   I
            0      27     0  args   [Ljava/lang/String;

Корпус с внутренней петлей

Code:
      stack=2, locals=3, args_size=1
         0: iconst_0
         1: istore_1
         2: iload_1
         3: sipush        1000
         6: if_icmpge     26
         9: iload_1
        10: iconst_2
        11: iadd
        12: istore_2
        13: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
        16: iload_2
        17: invokevirtual #3                  // Method java/io/PrintStream.println:(I)V
        20: iinc          1, 1
        23: goto          2
        26: return
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
           13       7     2 intermediateResult   I
            2      24     1     i   I
            0      27     0  args   [Ljava/lang/String;

Если вы обратите пристальное внимание, только Slot, назначенные i и intermediateResult в LocalVariableTable, меняются местами как результат их порядка появления. Такая же разница в слоте отражается в других строках кода.

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

БОНУС

Компиляторы делают массу оптимизаций, посмотрите, что в этом случае происходит.

Нулевой рабочий случай

for(int i=0; i < 1000; i++){
    int intermediateResult = i;
    System.out.println(intermediateResult);
}

Декомпилировано без работы

for(int i = 0; i < 1000; ++i) {
    System.out.println(i);
}

С точки зрения производительности, снаружи (намного) лучше.

public static void outside() {
    double intermediateResult;
    for(int i=0; i < Integer.MAX_VALUE; i++){
        intermediateResult = i;
    }
}

public static void inside() {
    for(int i=0; i < Integer.MAX_VALUE; i++){
        double intermediateResult = i;
    }
}

Я выполнил обе функции по 1 миллиарду раз каждую. external () занял 65 миллисекунд. inside () занял 1,5 секунды.

Я тестировал JS с Node 4.0.0, если кому-то интересно. Объявление вне цикла привело к повышению производительности примерно на 0,5 мс в среднем за 1000 испытаний со 100 миллионами итераций цикла за испытание. Так что я собираюсь сказать, продолжайте и напишите его наиболее читаемым / поддерживаемым способом, которым является B, imo. Я бы поместил свой код в скрипку, но я использовал модуль Node для повышения производительности. Вот код:

var now = require("../node_modules/performance-now")

// declare vars inside loop
function varInside(){
    for(var i = 0; i < 100000000; i++){
        var temp = i;
        var temp2 = i + 1;
        var temp3 = i + 2;
    }
}

// declare vars outside loop
function varOutside(){
    var temp;
    var temp2;
    var temp3;
    for(var i = 0; i < 100000000; i++){
        temp = i
        temp2 = i + 1
        temp3 = i + 2
    }
}

// for computing average execution times
var insideAvg = 0;
var outsideAvg = 0;

// run varInside a million times and average execution times
for(var i = 0; i < 1000; i++){
    var start = now()
    varInside()
    var end = now()
    insideAvg = (insideAvg + (end-start)) / 2
}

// run varOutside a million times and average execution times
for(var i = 0; i < 1000; i++){
    var start = now()
    varOutside()
    var end = now()
    outsideAvg = (outsideAvg + (end-start)) / 2
}

console.log('declared inside loop', insideAvg)
console.log('declared outside loop', outsideAvg)

A) более безопасный вариант, чем B) ......... Представьте, что если вы инициализируете структуру в цикле, а не int или float, что тогда?

нравиться

typedef struct loop_example{

JXTZ hi; // where JXTZ could be another type...say closed source lib 
         // you include in Makefile

}loop_example_struct;

//then....

int j = 0; // declare here or face c99 error if in loop - depends on compiler setting

for ( ;j++; )
{
   loop_example loop_object; // guess the result in memory heap?
}

Вы наверняка столкнетесь с проблемами утечки памяти !. Следовательно, я считаю, что «A» более безопасная ставка, в то время как «B» уязвима для накопления памяти, особенно при работе с библиотеками с близким исходным кодом. Вы можете проверить использование инструмента «Valgrind» в Linux, в частности вспомогательного инструмента «Helgrind».

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

Есть ли причина, по которой переменная должна быть глобальной?

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

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

это лучшая форма

double intermediateResult;
int i = byte.MinValue;

for(; i < 1000; i++)
{
intermediateResult = i;
System.out.println(intermediateResult);
}

1) таким образом однажды объявили раз обе переменные, а не каждую для цикла. 2) назначение жирнее всех остальных вариантов. 3) Таким образом, лучшим правилом практики является любое объявление вне итерации для.

Попробовал то же самое в Go и сравнил вывод компилятора с использованием go tool compile -S с go 1.9.4

Нулевая разница, согласно выводам ассемблера.

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

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

Вариант b) имеет для меня смысл только в том случае, если вам отчаянно нужно сделать intermediateResult недоступным после тела цикла. Но я все равно не могу представить себе такую ​​безвыходную ситуацию ....

РЕДАКТИРОВАТЬ: Джон Скит сделал очень хорошее замечание, показав, что объявление переменной внутри цикла может иметь реальную семантическую разницу.