Hallo,

wisst ihr welches der beiden Codevarianten schneller ist:

V1:

PHP-Code:

public String getString() {

if (1==1) return "ok";
i(f2==2) return "ok";
if name.equals("name") return "ok";
return "nicht ok";
} 


oder V2:

PHP-Code:

public String getString() {
 String buf;
 if (1==1) buf="ok";
 i(f2==2) buf="ok";
 if name.equals("name") buf="ok";
 buf="nicht ok";
return buf;
 } 


das Beispiel soll nur verdeutlichen das in V1 mehrere returns vorkommen und in V2 eben nur eines.

Aus Sicht der Lesbarkeit mag man sich streiten, wobei ich sagen würde das es hier ganz auf die Methode ankommt welche Lösung besser lesbar/verständlich ist. aber wie sieht es technisch aus?

Wenn der Compiler das ganze richtig übersetzt müsste die Variante 1 in jedem Fall schneller sein, da bei Ihr etliche Befehle gesparrt werden können ? wohingegen bei V2 immer jeder Befehl ausgeführt wird und durch die zusätzliche Zuweisung der Buffer Variablen sogar noch ein Befehl mehr ausgeführt wird.

Vielen Dank.

mfg Gideon

[Sym]

Hi,

ich denke mal, dass die erste Variante die schnellere ist, weil er ja gleich nach dem richtigen Punkt zurück springt.

Aber dafür ließe sich eigentlich auch relativ schnell ein Tester implementieren.

[sparrow]

Ich habe zwar keine praktische Handhabe, aber ich gehe davon aus, dass Variante 1 um einiges schneller ist.

Ich werde das heute Abend mal für dich in einem Feldversucht durchführen, falls es bis dahin noch niemand getan hat.

Variante sollte schon alleine wegen dem zusätzlichen String-Objekt langsamer sein. Strings sind ja dermaßen langsam... schier unglaublich.

Gruß
Sparrow

Hi,

naja logisch gesehen ist V1 schneller, aber es ist halt eher die Frage wie der Compiler das ganze übersetzt, wenn dieser aus variante 1 den gleichen Code erstellt wie aus v2 ist v1 eben nicht schneller. (bestes Beispiel hierfür ist ja die neu foreach Schleife die ja vom Compiler ganz genauso wie eine normale for Schleife übersetzt wird, man sparrt sich lediglich etwas schreibarbeit aber das wars dann auch schon, technisch ist beides gleich)

Ob die Methode Strings, boolsche Werte oder irgendwelche anderen Objekte zurück gibt ist völlig egal, weil es nicht darauf an kommt ob ein boolean schneller ist als ein String sonder ob viele returns schneller sind als eine Objektreferenz.

Naja die gemessene zeit wäre nur subjektiv, um wirklich zu wissen was schneller ist ohne das man weiß wie der Compiler den Code übersetzt müsste man die Taktezeiten berechnen, doch die kenne ich leider nicht genauso wenig wie die Maschinenbefehel die die VM absetzt.

Danke.

mfg Gideon

[sparrow]

Zitat von Gideon

Ob die Methode Strings, boolsche Werte oder irgendwelche anderen Objekte zurück gibt ist völlig egal, weil es nicht darauf an kommt ob ein boolean schneller ist als ein String sonder ob viele returns schneller sind als eine Objektreferenz.

Das stimmt so leider nicht.
Bei Strings ist es nicht egal, und in Variante 2 änderst du ja mit jeder auftreteten Eventualität den Inhalt eines String-Obejekts. Und das bremst unheimlich (buf).
Bei 1, 2 Durchläufen der Methode ist relativ egal, aber jag die Methode doch mal in ener Schleife ein paar Tausen mal durch.
Es geht hier auch nicht um den Rückgabewert, der Methode sondern um das String-Objekt "buf" innerhalb der Methode.

Zitat von Gideon

Naja die gemessene zeit wäre nur subjektiv, um wirklich zu wissen was schneller ist ohne das man weiß wie der Compiler den Code übersetzt müsste man die Taktezeiten berechnen, doch die kenne ich leider nicht genauso wenig wie die Maschinenbefehel die die VM absetzt.

Man könnte auch einfach die Methode in einer Schleife 5 Minuten unter gleichen Voraussetzungen durchlaufen lassen und mal schaun wer die meisten Runden um den Sportplatz schafft.

Gruß
Sparrow

Zitat von sparrow

Das stimmt so leider nicht.
Bei Strings ist es nicht egal, und in Variante 2 änderst du ja mit jeder auftreteten Eventualität den Inhalt eines String-Obejekts. Und das bremst unheimlich (buf).
Bei 1, 2 Durchläufen der Methode ist relativ egal, aber jag die Methode doch mal in ener Schleife ein paar Tausen mal durch.
Es geht hier auch nicht um den Rückgabewert, der Methode sondern um das String-Objekt "buf" innerhalb der Methode.

wie gesagt es geht mir nicht um Strings, ich hätte auch boolean oder ein eigenes Objekt XY nehmen können, technisch passiert das gleiche, der Zeiger der Variablen wird auf einen anderen Speicherblock gesetzt, da ist es egal ob in diesem Speicherblock ein String XY oder nen boolean steckt.

Was wirklich zählt ist eigentlich nur, wie der Compiler den Code übersetzt (bei C++ könne ich mir den Code mit einem Assemlber ansehen und würde sehen was der Compiler gemacht hat nur für Java kenne ich da leider nichts, da ja eh nur Bytecode erstellt wird der dann durch die VM ausgeführt wird).

mfg Gideon

[peschmae]

Da der Compiler bei 1 eh alles ausser der ersten Zeile wegoptimieren kann (und hoffentlich auch wird) wirds wohl schneller sein.

Ich glaube eher nicht dass aus der 2. derselbe Code generiert werden kann.


Aber jetzt mal von dem Spezialfall abgesehen habe ich schon von verschiedener Seite her gehört dass Code mit mehreren Returns in einer Funktion schwieriger zu Optimieren sei für den Compiler - k.A. wieso. Naja, ist mir auch egal - ich halte mich da an Donald Knuth: "Premature optimization is the root of all evil"

MfG Peschmä

Jepp, da die JavaVM ja nur das interpretiert, was sie benötigt und du dir in jedem fall durch das return am anfang alle anweisungen/bedingungen dahinter sparst ist es schneller.
Aber das ist ungefähr das gleiche, wenn ich eine Atombombe mit einer Wasserstoffbombe aus einer Entfernung von fünf Metern vergleiche: Die Wasserstoffbombe ist stärker, aber das interessiert mich dann auch nicht mehr, ich bin in jedem fall komplett platt.
Was ich sagen will ist, dass es nicht diese dinge sind, die Computer bremsen. Selbst wenn du dir da etwas performance herausschummelst (die allerdings absolut unerhebend ist) verlierst du das 10... 100... 1000 fache wenn du in deinem programm an einer wichten stelle einen schlechten algorithmus verwendest, der nicht notwendig wäre (beispielsweise ein Bubblesort anstelle von einem Quicksort)

Fazit: Programmier das wie du möchtest (und es am übersichtlichsten ist), aber kümmere dich um die Effizienz an den wichtigen stellen.

liebe grüße,
Matt