Nutzen, erst deklarieren, oder neu erstellen?

[DenialOfFavor]

Hallo,

ich habe eine Frage, die ich mir momentan nicht selbst beantworten kann, beziehungsweise wo ich mir nicht hunderprozentig sicher bin.

Object object;
        
        for (Object[] obj : objects) {
            
            object = obj;
            
            object...
        }
        
        /* Oder: */
        
        for (Object[] obj : objects) {
            
            Object object = obj;
            
            object...
        }

Also, mich interessiert jetzt, ob es einen Unterschied gibt. Verbraucht es mehr Ressourcen ein Objekt in einer for-Schleife immer neu zu erstellen und zu beschreiben, oder ist es sinnvoller, beziehungsweise spart es Ressourcen ein Object erst zu deklarieren und dann in einer for-Schleife immer zu beschreiben.

Ich denke Methode 2) ist deutlich effizienter, würde nur gerne Bestätigung bekommen.


EDIT:

Mein Beispiel ist jetzt schon ziemlich blöd. Stell Euch vor, dass das Objekt in dem Objekt-Array zum Erstellen eines neuen Objektes benötig wird. (new Objekt(obj.getX(), obj.getY(), obj.getHeight()), z.B..)

 

[xehpuk]

Da wird ja kein Objekt neu erstellt. Es wird lediglich eine zweite Referenz auf ein bestehendes Objekt erstellt.

Die zweite Version erzeugt einen kleineren Bytecode. Sie läuft vielleicht eine Nanosekunde schneller.

Im Grunde genommen geht es hier eher weniger um Performance, sondern mehr um Paradigmen. Und dort ist ganz klar die zweite Version vorzuziehen, da die Variable den kleinsten Scope erhält.

Ich frage mich allerdings, wieso du es nicht gleich so machst:

        for (Object[] obj : objects) {
            obj...
        }

 

[Marcinek]

Eine typische dennisXX frage.

Der Code ist so nicht mal kompilierbar, da du versuchst ein Array einem object zuzuordnen, das kein Array ist.

 

[faetzminator]

Marcinek, wie kommst du zu der Annahme, dass... *oh nein bitte nicht* ?
Abgesehen davon, dass das Beispiel des TO keinen grossen Sinn macht, weil man genau dafür die for-each Loop hat, man wählt Variante 2 wegen des Scopes der Variable. Mit einer "normalen" for-Schleife würde das Sinn machen:

Object obj;
for (int i = 0; i < list.size(); i++) {
    obj = list.get(i);
    // ...
}
// vs
for (int i = 0; i < list.size(); i++) {
    Object obj = list.get(i);
    // ...
}

Aber eben, Variante 1 ist IMHO strikte zu vermeiden.

 

[FArt]

Die VM optimiert am besten, wenn man nicht selber versucht es besser zu machen als der Optimizer.

Schreibt Standardcode. Haltet Scopes so klein wie möglich. Das ist logisch, besser zu lesen und wird (wenn möglich) von der VM sinnvoll optimiert.

Beispiel:

for (int i = 0; i < 10000000; i++) {
  MyObject o = new MyObject();
  ... // mache etwas mit o
}

Wenn die Instzen von o außerhalb des Scopes der for-Schleife nicht sichtbar sind (also auch nicht anderweitig gespeichert werden) werden hier nicht tausende Objekte angelegt und hinterher wieder vom GC verworfen. Die VM macht das besser.
Optimierungen dieser Art werden dadurch ausgehebelt, dass der Sichtbarkeitsscope künstlich vergrößert wird.

Noch mal: Standardcode ist besser als vermeintlich "optimierter" Code. Wir schreiben hier kein C.

 

[nillehammer]

...Noch mal: Standardcode ist besser als vermeintlich "optimierter" Code. Wir schreiben hier kein C.

War für mich jetzt zwar nicht wirklich neu. Aber man kann es nicht oft genug so deutlich wiederholen. Deswegen gab's auch ein "Danke".

 

[DenialOfFavor]

Hallo,

danke an alle. Danke an FArt. Das kann ich mir gut einprägen. (Scopes so klein wie möglich halten = besser für den Optimizer, beziehungsweise, erzielt besseres Ergebnis)

 

[Marco13]

WIE "intelligent" die tatsächlich im JDK umgesetzten Strategien diesbezüglich sind, weiß ich nicht, aber es KÖNNTE sein, dass der möglichst kleine Scope (neben der höheren Lesbarkeit) auch leichtere oder mehr Optimierungen bzgl. Escape Analysis erlaubt - im Prinzip das, was FUrz... äh FArt ( :bae: ) angedeutet hat....

 

[FArt]

WIE "intelligent" die tatsächlich im JDK umgesetzten Strategien diesbezüglich sind, weiß ich nicht, aber es KÖNNTE sein, dass der möglichst kleine Scope (neben der höheren Lesbarkeit) auch leichtere oder mehr Optimierungen bzgl. Escape Analysis erlaubt - im Prinzip das, was FUrz... äh FArt ( :bae: ) angedeutet hat....

Ich wollte keine warme Luft (hi hi) mit Fachbegriffen wie "Escape Analysis" erzeugen... vermutlich weil es mir nicht eingefallen ist, wie das Zeug jetzt genau heißt... ;-)

 

[Spacerat]

WIE "intelligent" die tatsächlich im JDK umgesetzten Strategien diesbezüglich sind, weiß ich nicht, aber es KÖNNTE sein, dass der möglichst kleine Scope (neben der höheren Lesbarkeit) auch leichtere oder mehr Optimierungen bzgl. Escape Analysis erlaubt...

Da es sich beim Bytecode um Assembler ähnliche Opcodes handelt, sollte man fast annehmen, dass die JVM auch Assembler ähnlich ihre Scopes anlegt (das wäre nebenbei auch 'ne Erklärung dafür, warum es in Java kein Call-By-Value gibt). Im simpelsten Fall also einfach das Verbiegen eines Stapelzeigers (Userstack) um für die im Scope verwendeten Variablen und Parameter notwendige Anzahl an Bytes. Eine Escapeanalyse reduziert sich dann entsprechend auf das Zurücksetzen dieses Zeigers beim Scope-Exit. (Vgl. CDECL)

 

[Marco13]

Wie gesagt, was da genau abläuft ist schwer zu sagen. Irgendwann hatte ich mal angefangen ein bißchen was zu lesen ( http://www.ssw.uni-linz.ac.at/Research/Papers/Ko05b/phd-kotzmann.pdf oder auch http://www.dsi.unive.it/~avp/blanchet.pdf ) aber ... (ja, wenn man glaubt, "ein bißchen Ahnung von Java" zu haben...) : Das geht schon recht schnell an's Eingemachte...

 

[Spacerat]

Wow... jetzt hab' ich auch verstanden, wobei es um Escapeanalyse geht...
Wie es aussieht, legt der JIT die Scopes genau so an, wie ich es oben beschrieben habe. Die EA wird nur beim kompilieren eines Scopes (Klasse, Methode, Schleife) in nativen Code durchgeführt und betrifft ausschlieslich Instanzen, die innerhalb eines solchen Scopes angelegt werden (z.B. new-Operator). Das bedeutet, dass Objekte nicht mehr zwangsläufig im Heap angelegt werden, sondern das evtl. der Userstack damit belastet wird. Der Vorteil ist klar. der GC muss um auf dem Stack angelegte Objekte beim verlassen eines Scopes nicht mehr kümmern, diese sind bereits dann Geschichte, wenn der Pointer zurückgesetzt wurde. Hab' zwar noch nicht rausgefunden, wann der JIT ein Objekt auf dem Stack alloziieren lässt, aber ich bin ja auch noch am Anfang der PDFs.
Für den TO ist das aber wahrscheinlich relativ unwichtig. Er will ja nur wissen, wo man seine Objekte am sinnvollsten deklariert.