Lohnen sich If abfragen vor dem schreiben auf einen Wert?

[snow]

Hallo

Ich hab mal eine Frage und zwar.

Wenn ich in einer eigenden Komponente eine SetXXX procedure habe.

Loht es sich dann vor dem schreiben auf der variable zu überprüfen ob sich der neue wert von dem alten unterscheidet(preformancemäßig).


Hier mal als Beispiel...

Delphi-Quellcode:

procedure TBeispielComp.SetZahl2(Value: Integer);
begin
  if Value <> FZahl2 then
    FZahl2 := Value;
end;

gruß snow

Frohe Weihnachten :xmas:

[Popov]

Zwar dauert das Schreiben auch seine Zeit, aber das Überprüfen auch. Du wirst also keine Zeitersparnis haben. Wobei die Frage ist ob es nur um einer Variable geht oder du pro Sekunde 10000 Variablen zuweisen willst. Hier könnte man sich Gedanken machen, aber nicht bei einzelnen Variablen.

Wahrscheinlich kommt deine Frage, weil du bei einem Stick festgestellt hast, daß das Schreiben x mal länger dauert wie lesen. Aber wir sprechen hier von Nanosekunden bei RAM.

[3_of_8]

Im Normalfall wirbelt so ein if die Pipeline des Prozessors ordentlich durcheinander. Das hat zwar nicht allzugroße Auswirkungen, man sollte es aber berücksichtigen. Ein Speicherzugriff hingegen dauert schon so einige Zeit, ich würde mal schätzen je nach Leistungsfähigkeit des Prozessors zwischen 50 und 180 Taktzyklen. Das kostet natürlich richtig übel Zeit. Allerdings haben Prozessoren heutzutage natürlich ziemlich große Caches mit recht niedrigen Fehlzugriffsraten.

Man kann also wirklich sagen, dass sich diese beiden Varianten nicht viel nehmen. Vermutlich gibt es viel bessere Optimierungsmöglichkeiten im Rest des Codes, und die paar Nanosekunden hin oder her machen natürlich eh keinen spürbaren Unterschied, solange du das ganze nicht ein paar hunderttausendmal aufrufst. Ich würde die ohne if-Abfrage aus Gründen der Einfachheit bevorzugen.

[Popov]

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  i, x: Integer;
  Start, Ende, Zeit: TDateTime;
begin
  x := 0;
  Start := Now;

  for i := 0 to 2147483647 do
  begin
    (*Variante 1: Hier wird der Wert nur ein einziges Mal übergeben*)
    if i = 0 then x := i;

    (*Variante 2: Hier wird der Wert jedes Mal übergeben*)
    //x := i;
  end;

  Ende := Now;
  Zeit := Ende - Start;

  ShowMessage('Fertig bei x = ' + IntToStr(x) + ^j + 'Dauer: ' + TimeToStr(Zeit));
end;

Hab mal schnell etwas gebastelt. Es geht zwar genauer, aber für grobe Berechnung reicht es.

Laut der Routine dauert es doppelt so lange bei 2147483647 Abfragen und nur einer Zuweiseung, als wenn der Wert 2147483647 Mal übergeben wird.

[Dax]

Das ist auch kein Wunder, wenn man den Maschinencode vergleicht..

Delphi-Quellcode:

// EAX: i, EDX: x

// mit Prüfung

cmp eax, edx
je @@done
mov eax, edx
@@done:

// ohne Prüfung

mov eax, edx

Da die Sprungvorhersage bei modernen Prozessoren schon so sehr ausgereift ist, dass die Fehlerwahrscheinlichkeit bei statischen Daten gegen 0 geht, wirkt sich der Sprung kaum aus, so bleibt es bei CMP/MOV mit Prüfung und bei MOV ohne Prüfung. Wenn es später an fetter Brocken geht, sagen wir, Dateisystemobjekte, macht eine Prüfung aber durchaus Sinn: beschreiben beide Werte das selbe Objekt, tut man einfach nichts, tun sie nicht, räumt man das Objekt (möglicherweise kostspielig) auf, bevor man sich auf das neue festlegt.

[Sharky]

Zitat:

Zitat von snow

.... ob sich der neue wert von dem alten unterscheidet(preformancemäßig). ...

Hai snow,

wegen der Geschwindigkeit wurde ja schon etwas gesagt. Ein Grund für eine solche Abfrage könnte sein das Du deiner Komponente ein OnChange-Ereigniss schenken möchtest wenn sich der Wert von FZahl2 ändert.

[DeddyH]

In meinen Komponenten mache ich diese Abfragen dann, wenn eine Änderung größere Rechenoperationen wie z.B. Neuzeichnen auslöst.

[Die Muhkuh]

Zitat:

Zitat von DeddyH

In meinen Komponenten mache ich diese Abfragen dann, wenn eine Änderung größere Rechenoperationen wie z.B. Neuzeichnen auslöst.

Das ist ja auch mehr als logisch. ;-) Lieber ein paar Taktzyklen für die Abfrage verschwenden, als die ganze Power zum Rechnen und Neuzeichnen nutzen.

[DeddyH]

Eben ;)

[grenzgaenger]

Zitat:

Zitat von Popov

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  i, x: Integer;
  Start, Ende, Zeit: TDateTime;
begin
  x := 0;
  Start := Now;

  for i := 0 to 2147483647 do
  begin
    (*Variante 1: Hier wird der Wert nur ein einziges Mal übergeben*)
    if i = 0 then x := i;

    (*Variante 2: Hier wird der Wert jedes Mal übergeben*)
    //x := i;
  end;

  Ende := Now;
  Zeit := Ende - Start;

  ShowMessage('Fertig bei x = ' + IntToStr(x) + ^j + 'Dauer: ' + TimeToStr(Zeit));
end;

Hab mal schnell etwas gebastelt. Es geht zwar genauer, aber für grobe Berechnung reicht es.

Laut der Routine dauert es doppelt so lange bei 2147483647 Abfragen und nur einer Zuweiseung, als wenn der Wert 2147483647 Mal übergeben wird.

tja, das beispiel ist so gewählt, dass man sich die abfrage schenken kann, sie ist redundant. daher ist es nicht verwunderlich, dass der compi länger braucht, muss ja zwei mal den speicherzugriff machen.

aber normal ist es so, dass z.b. nicht nur 'ne seicherstelle gesetzt wird, mit der der processor prima umgehen kann (integer), sondern etwas complexeres... z.b. byte, string, record, objekt... und da sind die kosten der zuweisung höher, als für den vergleich.

ausserdem, kann man in einer solchen abfrage auch noch zusätzliche funktionen durchführen, z.b. 'n modified flag setzen... und hier ist es dann wichtig, dass das nicht immer gesetzt wird, sondern nur, wenn sich wirklich etwas geändert hat.

[alzaimar]

Ich würde aus Gründen der Selbstdisziplin grundsätzlich in einer Setter-Methode prüfen, ob das private Feld nicht schon den Wert enthält. Wenn ich das am Anfang gleich mache, dann habe ich später keine Probleme, die Setter-Methode auf die Schnelle (also unter Zeitdruck) zu erweitern.

Ich würde die paar Taktzyklen ohnehin ignorieren, schließlich geht es hier um OOP und nicht um Nanosekunden-Performance.

Am Anfang mag das wirklich bescheuert aussehen, aber es ist konsistent...