Unterschied zwischen der Deklaration von Variablen vor oder in der Schleife?

Ich habe mich immer gefragt, ob es im Allgemeinen einen (Leistungs-) Unterschied macht, eine Wegwerfvariable vor einer Schleife zu deklarieren, anstatt sie wiederholt innerhalb der Schleife zu deklarieren. Ein (ziemlich sinnloses) Beispiel in Java:

a) Deklaration vor Schleife:

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

b) Deklaration (wiederholt) innerhalb der Schleife:

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

Welches ist besser, a oder b ?

Ich vermute, dass eine wiederholte Variablendeklaration (Beispiel b ) theoretisch mehr Overhead verursacht , aber dass Compiler klug genug sind, damit es keine Rolle spielt. Beispiel b hat den Vorteil, dass es kompakter ist und den Umfang der Variablen auf den Verwendungsort beschränkt. Trotzdem neige ich dazu, gemäß Beispiel a zu codieren .

Edit: Ich interessiere mich besonders für den Java-Fall.

Was ist besser, a oder b ?

Aus Sicht der Leistung müssten Sie es messen. (Und meiner Meinung nach ist der Compiler nicht sehr gut, wenn Sie einen Unterschied messen können).

Aus Wartungssicht ist b besser. Deklarieren und initialisieren Sie Variablen an derselben Stelle im engstmöglichen Rahmen. Lassen Sie keine Lücke zwischen der Deklaration und der Initialisierung und verschmutzen Sie keine Namespaces, die Sie nicht benötigen.

Nun, ich habe Ihre A- und B-Beispiele jeweils 20 Mal ausgeführt und 100 Millionen Mal wiederholt. (JVM - 1.5.0)

A: durchschnittliche Ausführungszeit: 0,074 Sek

B: durchschnittliche Ausführungszeit: 0,067 Sek

Zu meiner Überraschung war B etwas schneller. So schnell wie Computer jetzt sind, ist es schwer zu sagen, ob Sie dies genau messen können. Ich würde es auch so wie A codieren, aber ich würde sagen, dass es nicht wirklich wichtig ist.

Das hängt von der Sprache und der genauen Verwendung ab. Zum Beispiel machte es in C # 1 keinen Unterschied. Wenn in C # 2 die lokale Variable von einer anonymen Methode (oder einem Lambda-Ausdruck in C # 3) erfasst wird, kann dies einen sehr signifikanten Unterschied bewirken.

Beispiel:

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();
        }
    }
}

Ausgabe:

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

Der Unterschied besteht darin, dass alle Aktionen dieselbe outerVariable erfassen , aber jede ihre eigene separate innerVariable hat.

Folgendes habe ich in .NET geschrieben und kompiliert.

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);
}

Dies ist, was ich von .NET Reflector bekomme, wenn CIL wieder in Code gerendert wird.

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);
}

So sehen beide nach der Kompilierung genau gleich aus. In verwalteten Sprachen wird Code in CL / Byte-Code konvertiert und zum Zeitpunkt der Ausführung in Maschinensprache konvertiert. In der Maschinensprache wird möglicherweise nicht einmal ein Double auf dem Stapel erstellt. Es kann nur ein Register sein, da der Code widerspiegelt, dass es sich um eine temporäre Variable für die WriteLineFunktion handelt. Es gibt eine ganze Reihe von Optimierungsregeln nur für Schleifen. Der Durchschnittsbürger sollte sich also keine Sorgen machen, insbesondere in verwalteten Sprachen. Es gibt Fälle, in denen Sie den Verwaltungscode optimieren können, z. B. wenn Sie eine große Anzahl von Zeichenfolgen mit just string a; a+=anotherstring[i]vs using verketten müssenStringBuilder. Es gibt einen sehr großen Leistungsunterschied zwischen beiden. Es gibt viele solcher Fälle, in denen der Compiler Ihren Code nicht optimieren kann, weil er nicht herausfinden kann, was in einem größeren Bereich beabsichtigt ist. Aber es kann so ziemlich grundlegende Dinge für Sie optimieren.

Dies ist ein Gotcha in VB.NET. Das Visual Basic-Ergebnis initialisiert die Variable in diesem Beispiel nicht neu:

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

' Output: 0 1 2 3 4...

Dies gibt beim ersten Mal 0 aus (Visual Basic-Variablen haben beim Deklarieren Standardwerte!), Aber ijedes Mal danach.

Wenn Sie jedoch ein hinzufügen = 0, erhalten Sie das, was Sie erwarten könnten:

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

'Output: 0 0 0 0 0...

Ich habe einen einfachen Test gemacht:

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

vs.

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

Ich habe diese Codes mit gcc - 5.2.0 kompiliert. Und dann habe ich das main () dieser beiden Codes zerlegt und das ist das Ergebnis:

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 

Welches sind genau die gleichen wie das Ergebnis. Ist das nicht ein Beweis dafür, dass die beiden Codes dasselbe produzieren?

Es ist sprachabhängig - IIRC C # optimiert dies, sodass es keinen Unterschied gibt, aber JavaScript (zum Beispiel) übernimmt jedes Mal die gesamte Speicherzuweisung.

Ich würde immer A verwenden (anstatt mich auf den Compiler zu verlassen) und könnte auch Folgendes umschreiben:

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

Dies beschränkt sich immer noch auf intermediateResultden Bereich der Schleife, wird jedoch nicht bei jeder Iteration neu deklariert.

Meiner Meinung nach ist b die bessere Struktur. In a bleibt der letzte Wert von intermediärem Ergebnis erhalten, nachdem Ihre Schleife beendet wurde.

Bearbeiten: Dies macht bei Werttypen keinen großen Unterschied, aber Referenztypen können etwas gewichtig sein. Persönlich möchte ich, dass Variablen so schnell wie möglich zur Bereinigung dereferenziert werden, und b erledigt das für Sie.

Ich vermute, einige Compiler könnten beide so optimieren, dass sie der gleiche Code sind, aber sicherlich nicht alle. Also würde ich sagen, dass Sie mit dem ersteren besser dran sind. Der einzige Grund für Letzteres ist, wenn Sie sicherstellen möchten, dass die deklarierte Variable nur in Ihrer Schleife verwendet wird.

In der Regel deklariere ich meine Variablen im innerstmöglichen Bereich. Wenn Sie IntermediateResult nicht außerhalb der Schleife verwenden, würde ich mich für B entscheiden.

Ein Mitarbeiter bevorzugt das erste Formular und gibt an, dass es sich um eine Optimierung handelt. Er zieht es vor, eine Deklaration wiederzuverwenden.

Ich bevorzuge den zweiten (und versuche meinen Kollegen zu überzeugen! ;-)), nachdem ich Folgendes gelesen habe:

• Es reduziert den Umfang der Variablen auf den Ort, an dem sie benötigt werden, was gut ist.
• Java optimiert genug, um keinen signifikanten Unterschied in der Leistung zu machen. IIRC, vielleicht ist die zweite Form noch schneller.

Auf jeden Fall fällt es in die Kategorie der vorzeitigen Optimierung, die von der Qualität des Compilers und / oder der JVM abhängt.

Es gibt einen Unterschied in C #, wenn Sie die Variable in einem Lambda usw. verwenden. Im Allgemeinen wird der Compiler jedoch im Grunde das Gleiche tun, vorausgesetzt, die Variable wird nur innerhalb der Schleife verwendet.

Da sie im Grunde genommen gleich sind: Beachten Sie, dass Version b den Lesern viel deutlicher macht, dass die Variable nach der Schleife nicht verwendet werden kann und kann. Darüber hinaus lässt sich Version b viel einfacher umgestalten. In Version a ist es schwieriger, den Schleifenkörper in eine eigene Methode zu extrahieren. Darüber hinaus versichert Ihnen Version b, dass ein solches Refactoring keine Nebenwirkungen hat.

Daher nervt mich Version a ohne Ende, weil es keinen Nutzen bringt und es viel schwieriger macht, über den Code nachzudenken ...

Nun, dafür könnte man immer einen Spielraum schaffen:

{ //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);
    }
}

Auf diese Weise deklarieren Sie die Variable nur einmal und sie stirbt, wenn Sie die Schleife verlassen.

Ich habe immer gedacht, dass Sie Speicher verschwenden, wenn Sie Ihre Variablen innerhalb Ihrer Schleife deklarieren. Wenn Sie so etwas haben:

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

Dann muss nicht nur das Objekt für jede Iteration erstellt werden, sondern es muss auch eine neue Referenz für jedes Objekt zugewiesen werden. Es scheint, dass wenn der Garbage Collector langsam ist, Sie eine Reihe von baumelnden Referenzen haben, die bereinigt werden müssen.

Wenn Sie jedoch Folgendes haben:

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

Dann erstellen Sie nur eine einzelne Referenz und weisen ihr jedes Mal ein neues Objekt zu. Sicher, es kann etwas länger dauern, bis es außerhalb des Anwendungsbereichs liegt, aber dann gibt es nur einen baumelnden Hinweis, mit dem man sich befassen muss.

Ich denke, es hängt vom Compiler ab und es ist schwierig, eine allgemeine Antwort zu geben.

Meine Praxis ist folgende:

• Wenn der Variablentyp einfach ist (int, double, ...), bevorzuge ich Variante b (innen).
  Grund: Reduzierung des Variablenumfangs.

• Wenn der Variablentyp nicht einfach ist (irgendeine Art von classoder struct), bevorzuge ich Variante a (außerhalb).
  Grund: Reduzierung der Anzahl der ctor-dtor-Aufrufe.

Aus Sicht der Leistung ist draußen (viel) besser.

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;
    }
}

Ich habe beide Funktionen jeweils 1 Milliarde Mal ausgeführt. außerhalb () dauerte 65 Millisekunden. inside () dauerte 1,5 Sekunden.

Ich habe mit Node 4.0.0 auf JS getestet, wenn jemand interessiert ist. Das Deklarieren außerhalb der Schleife führte zu einer Leistungsverbesserung von ~ 0,5 ms im Durchschnitt über 1000 Versuche mit 100 Millionen Schleifeniterationen pro Versuch. Also werde ich sagen, mach weiter und schreibe es auf die lesbarste / wartbarste Art und Weise, nämlich B, imo. Ich würde meinen Code in eine Geige stecken, aber ich habe das Performance-Now-Node-Modul verwendet. Hier ist der Code:

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) ist eine sichere Wette als B) ......... Stellen Sie sich vor, Sie initialisieren die Struktur in einer Schleife und nicht 'int' oder 'float'. Was dann?

mögen

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?
}

Sie werden sicherlich Probleme mit Speicherlecks haben!. Daher glaube ich, dass 'A' sicherer ist, während 'B' anfällig für Speicherakkumulation ist, insbesondere wenn enge Quellbibliotheken verwendet werden. Sie können die Verwendung des 'Valgrind'-Tools unter Linux überprüfen, insbesondere des Sub-Tools' Helgrind '.

Das ist eine interessante Frage. Aus meiner Erfahrung ist eine letzte Frage zu berücksichtigen, wenn Sie diese Angelegenheit für einen Kodex diskutieren:

Gibt es einen Grund, warum die Variable global sein muss?

Es ist sinnvoll, die Variable nur einmal global und nicht mehrmals lokal zu deklarieren, da dies für die Organisation des Codes besser ist und weniger Codezeilen erfordert. Wenn es jedoch nur lokal innerhalb einer Methode deklariert werden muss, würde ich es in dieser Methode initialisieren, damit klar ist, dass die Variable ausschließlich für diese Methode relevant ist. Achten Sie darauf, diese Variable nicht außerhalb der Methode aufzurufen, in der sie initialisiert wird, wenn Sie die letztere Option auswählen. Ihr Code weiß nicht, wovon Sie sprechen, und meldet einen Fehler.

Als Randnotiz sollten Sie auch keine lokalen Variablennamen zwischen verschiedenen Methoden duplizieren, auch wenn ihre Zwecke nahezu identisch sind. es wird nur verwirrend.

Das ist die bessere Form

double intermediateResult;
int i = byte.MinValue;

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

1) auf diese Weise einmal beide Variablen und nicht jede für den Zyklus deklariert. 2) Die Zuordnung ist fetter als alle anderen Optionen. 3) Die Best-Practice-Regel ist also jede Deklaration außerhalb der Iteration für.

Versuchte dasselbe in Go und verglich die Compiler-Ausgabe go tool compile -Smit go 1.9.4

Nulldifferenz gemäß Assembler-Ausgabe.

Ich hatte lange die gleiche Frage. Also habe ich einen noch einfacheren Code getestet.

Schlussfolgerung: In solchen Fällen gibt es KEINEN Leistungsunterschied.

Außenschleifenkasten

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

Innenschleifenkoffer

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

Ich habe die kompilierte Datei auf dem IntelliJ-Dekompiler überprüft und in beiden Fällen das gleiche erhalten Test.class

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

Ich habe auch Code für beide Fälle mit der in dieser Antwort angegebenen Methode zerlegt . Ich werde nur die Teile zeigen, die für die Antwort relevant sind

Außenschleifenkasten

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;

Innenschleifenkoffer

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;

Wenn Sie genau hinschauen, wird nur das Slotzugewiesene iund intermediateResultin LocalVariableTableals Produkt ihrer Erscheinungsreihenfolge ausgetauscht. Der gleiche Unterschied im Steckplatz spiegelt sich in anderen Codezeilen wider.

• Es wird keine zusätzliche Operation ausgeführt
• intermediateResult ist in beiden Fällen immer noch eine lokale Variable, daher gibt es keinen Unterschied bei der Zugriffszeit.

BONUS

Compiler optimieren eine Menge, schauen Sie sich an, was in diesem Fall passiert.

Null Arbeitsfall

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

Null Arbeit dekompiliert

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

Selbst wenn ich weiß, dass mein Compiler klug genug ist, möchte ich mich nicht darauf verlassen und werde die Variante a) verwenden.

Die Variante b) ist für mich nur dann sinnvoll, wenn Sie das IntermediateResult nach dem Loop-Body unbedingt nicht mehr verfügbar machen müssen . Aber ich kann mir eine so verzweifelte Situation sowieso nicht vorstellen ...

EDIT: Jon Skeet machte einen sehr guten Punkt und zeigte, dass die Variablendeklaration innerhalb einer Schleife einen tatsächlichen semantischen Unterschied machen kann.