Zeit sparen bei mehrfachem Funktionsaufruf
-
kauflummi schrieb:
die Variable nicht jedes mal neu deklarieren zu müssen?
Das ist egal. Wird vom Compiler wegoptimiert, und selbst wenn nicht, sind Speicheranforderungen an den Stack so ziemlich das Schnellste was es gibt.
-
Danke für die Antworten.
-
cooky451 schrieb:
kauflummi schrieb:
die Variable nicht jedes mal neu deklarieren zu müssen?
Das ist egal. Wird vom Compiler wegoptimiert, und selbst wenn nicht, sind Speicheranforderungen an den Stack so ziemlich das Schnellste was es gibt.
Um genau zu sein normalerweise nur eine Subtraktion.
-
cooky451 schrieb:
kauflummi schrieb:
die Variable nicht jedes mal neu deklarieren zu müssen?
Das ist egal.
Würde ich nicht sagen, ich würde im Gegenteil davon absehen, den buffer als Membervariable zu definieren, da das den Compiler ggf. dazu zwingt, den this-Pointer zu dereferenzieren, was dazu führen kann, dass je nach Lage des Objekts Speicher in den Cache geladen werden muss usw., schließlich muss der Wert auf jeden Fall im Objekt gespeichert werden. Bei einer funktionslokalen temporären Variable hat der Compiler dagegen extrem gute Chancen, die Variable komplett wegzuoptimieren und den Wert einfach in einem Register zwischenzulagern.
-
Der stack pointer wird nicht bei jeder Variablen verschoben, sondern eher einmal pro Funktion und damit sowieso, also unabhängig von der Hilfsvariablen.
-
-
clock() ist je nach Implementierung nicht ganz billig, d.h. in engen Schleifen eher damit sparen.
-
Was du machst sieht mir danach aus, als ob sowieso nur die "gepufferte" Variante in Frage kommt. Falls nämlich zwischen Zeile 1 und 2 deiner Variante (1) ein Clock-Tick passiert, dann "verlierst" du den in der Berechnung. Das will man normalerweise nicht.
Also entweder Variante (2) oder (3). (3) ist IMO Blödsinn. Kann in Spezialfällen vielleicht Sinn machen, aber (2) ist die Übliche Variante.
Je nachdem was du programmierst kann es aber auch Sinn machen die Zeit in den einzelnen Funktionen gar nicht abzufragen, sondern als Parameter mitzugeben. Oder ggf. über einen speziellen Getter zugänglich zu machen, der allerdings auch einen gepufferten Wert zurückgibt.
Bei Spielen macht man es z.B. üblicherweise so - also pro Update nur 1x zentral die Clock abfragen, und alle Programmteile verwenden dann diesen gepufferten Wert.
-
-
pumuckl schrieb:
cooky451 schrieb:
kauflummi schrieb:
die Variable nicht jedes mal neu deklarieren zu müssen?
Das ist egal.
Würde ich nicht sagen, ich würde im Gegenteil davon absehen, den buffer als Membervariable zu definieren, da das den Compiler ggf. dazu zwingt, den this-Pointer zu dereferenzieren, was dazu führen kann, dass je nach Lage des Objekts Speicher in den Cache geladen werden muss usw., schließlich muss der Wert auf jeden Fall im Objekt gespeichert werden. Bei einer funktionslokalen temporären Variable hat der Compiler dagegen extrem gute Chancen, die Variable komplett wegzuoptimieren und den Wert einfach in einem Register zwischenzulagern.
Und ich wiederum würde die Entscheidung Member/Lokal nicht davon abhängig machen was vielleicht schneller ist, sondern was konzeptionell "richtiger" ist.
-
hustbaer schrieb:
Und ich wiederum würde die Entscheidung Member/Lokal nicht davon abhängig machen was vielleicht schneller ist, sondern was konzeptionell "richtiger" ist.
Davon mal ganz abgesehen, ja. Der OP hat aber nach Schnelligkeit gefragt und ich hab ausnahmsweise mal drauf verzichtet, mein übliches "machs gut bevor dus schnell machst" Gemecker vom Stapel zu lassen
-
Hihi, OK
-
Wie wäre es damit?
speed = (clock() - lastclock) / 25; lastclock = speed * 25 + lastclock;Weis jetzt nicht ob das schneller ist, aber man spart den Puffer
-
pyhax schrieb:
Weis jetzt nicht ob das schneller ist, aber man spart den Puffer
Pro:
+ man spart den PufferContra:
- der gesparte Puffer wird eh wegoptimiert -> Pluspunkt ist keiner
- man machts unnötig unübersichtlich, unter anderem weil man den Puffer spart
- Man holt sich durch die zusätzliche Multiplikation noch einen Performancenachteil, wenn der Compiler das Gemurkse nicht auflöst. (Multiplikationen und vor allem Divisionen sind ungleich teurer als Addition/Subtraktion)
