Tricks um Programm zu beschleunigen

[Jasocul]

Zitat von mumu:

Zitat:

Fehlerbehandlung selbst übernehmen. Try..Except ist eine Todesfalle schnellen Code.

soweit ich aber weiß ist das jedoch nur beim debug zeitpunkt so. in der runtime umgebung sollte ein try except nicht wirklich sehr performance schädigend sein, oder? ich mein der stack, lokale Variablen, und weitere informationen werden bei einer exception bei debuggen gesammelt und deshalb ist hier das programm langsamer, oder?

Auch zur Laufzeit ein echtes Problem. Weiß ich aus leidvoller, eigener Erfahrung. Besonders schlimm wird es, wenn die Exception auch noch regelmäßig ausgelöst wird.

[alzaimar]

Ich will Dir ja nicht widersprechen, aber so gewaltig sind die Unterschiede nicht:

Delphi-Quellcode:

Var
  c,i : Cardinal;
  r : Real;

begin
  c := getTickCount;
  r := 0;
  For i:=1 to 20000000 do r:=r+r/i;
  memo.Lines.Add(intToStr (GetTickcount - c));
  c := getTickCount;
  r := 0;
  For i:=1 to 20000000 do try r:=r+r/i; except end;
  memo.Lines.Add(intToStr (GetTickcount - c));
end;

ergibt bei mir hier 500 und 620 (ca.) Ticks... Ob da was wegoptimiert wird, weiss ich nicht.

Allerdings, da geb ich Dir Recht, kommt man irgendwann dahin, das die 20% Performanceunterschied ein echtes Erfolgserlebnis sind: Wenn nämlich sonst kaum noch was rauszuholen ist.

[mumu]

Zitat von alzaimar:

Ich will Dir ja nicht widersprechen, aber so gewaltig sind die Unterschiede nicht:

Delphi-Quellcode:

Var
  c,i : Cardinal;
  r : Real;

begin
  c := getTickCount;
  r := 0;
  For i:=1 to 20000000 do r:=r+r/i;
  memo.Lines.Add(intToStr (GetTickcount - c));
  c := getTickCount;
  r := 0;
  For i:=1 to 20000000 do try r:=r+r/i; except end;
  memo.Lines.Add(intToStr (GetTickcount - c));
end;

ergibt bei mir hier 500 und 620 (ca.) Ticks... Ob da was wegoptimiert wird, weiss ich nicht.

Allerdings, da geb ich Dir Recht, kommt man irgendwann dahin, das die 20% Performanceunterschied ein echtes Erfolgserlebnis sind: Wenn nämlich sonst kaum noch was rauszuholen ist.

naja so in etwa hätte ich mir das auch vorgestellt. exceptions sind zwar (meiner meinung nach, die Indys haben da ja eine andere Meinung) unsaubere Programmierung und sollten eigentlich wirklich nur bei gravierenden Fehlern auftauchen, jedoch zur runtime nicht sehr performance schädigend.

[alzaimar]

Zitat von mumu:

exceptions sind zwar (meiner meinung nach, die Indys haben da ja eine andere Meinung) unsaubere Programmierung und sollten eigentlich wirklich nur bei gravierenden Fehlern auftauchen...

Wieso? Irgendwie muss man ja falsche Parameter ('Design by contract') ablehnen.
Variante A: Die Routinen liefern True, wenn alles im Lot sind und False sonst.

Delphi-Quellcode:

If EineProcedure Then
  If DieNaechsteProcedure Then
    If NochEineProcedure Then
      If EndlichDieLetzteProcedure Then
         Output ('Alles ok')
      else
        Output ('Hupsa')
    else
      Output ('Hupsa')
  else
    Output ('Hupsa')
else
  Output ('Hupsa');

Variante B: Die Routinen erzeugen eine Exception wenn irgendwas faul ist:

Delphi-Quellcode:

Try
  EineProcedure;
  DieNaechsteProcedure;
  NochEineProcedure;
  EndlichDieLetzteProcedure;
  Output ('Alles ok');
Except
  Output ('Hupsa');
End;

Also, ich finde 'B' übersichtlicher. Das einzige, was nervt, ist das Debuggen. Aber wenn man die Prozeduren spezielle Exceptions ('EMyException') auslösen lässt, kann man die auch wegfiltern.

Aber zurück zum Thema...

[Jasocul]

Dann testet doch mal eure Routinen, indem ihr alle 1000 Durchläufe eine Exception auslöst. Das dürfte ganz erhebliche Performance einbußen bringen. Baut doch einfach mal eine Division durch Null ein:

Delphi-Quellcode:

Var
  c,i : Cardinal;
  r : Real;

begin
  c := getTickCount;
  r := 0;
  For i:=1 to 20000000 do 
  begin
    if (i div 1000) = (i/1000) then 
      r := r
    else
      r:=r+r/i;
  end;
  memo.Lines.Add(intToStr (GetTickcount - c));
  c := getTickCount;
  r := 0;
  For i:=1 to 20000000 do 
  begin
    try
      if (i div 1000) = (i/1000) then 
        r := r / 0;
      else
        r:=r+r/i;
    except
    end;
  end;
  memo.Lines.Add(intToStr (GetTickcount - c));
end;

Habe das jetzt nicht bei mir geprüft, aber das Ergebnis sollte deutlich sein.

@alzaimar:
Hier gehts doch nicht um Übersichtlichkeit.

[tigerman33]

Also letztendlich muss man ja des öfteren eine Entscheidung zwischen übersichtlichem Code und maximaler Geschwindigkeit treffen. Und bei exceptions nehme ich da Geschwindigkeitseinbußen gerne in Kauf.

Und Code, der mit der von dir beschriebenen Regelmäßigkeit Exceptions auslöst, macht IMHO sowieso was falsch. "Exception" heißt ja nicht umsonst "Ausnahme", und als solche sollte sie auch verstanden werden, nicht als reguläres Kommunikationsmittel. Dafür gibt es andere (schnellere!) Varianten.

// edit:

Zitat:

Hier gehts doch nicht um Übersichtlichkeit.

Vielleicht nicht direkt, im Kontext aber schon. Denn beim "Wegoptimieren" sollte man sich schon überlegen, ob der Geschwindigkeitsvorteil es jetzt tatsächlich wert ist, solchen Spaghetticode wie die verschachtelten Aufrufe (s.o.) in Kauf zu nehmen.

BTW: Wer kann denn einen einfach zu bedienenden (Freeware-)Profiler empfehlen?

[mumu]

Zitat von alzaimar:

Zitat von mumu:

exceptions sind zwar (meiner meinung nach, die Indys haben da ja eine andere Meinung) unsaubere Programmierung und sollten eigentlich wirklich nur bei gravierenden Fehlern auftauchen...

Wieso? Irgendwie muss man ja falsche Parameter ('Design by contract') ablehnen.
Variante A: Die Routinen liefern True, wenn alles im Lot sind und False sonst.

Delphi-Quellcode:

If EineProcedure Then
  If DieNaechsteProcedure Then
    If NochEineProcedure Then
      If EndlichDieLetzteProcedure Then
         Output ('Alles ok')
      else
        Output ('Hupsa')
    else
      Output ('Hupsa')
  else
    Output ('Hupsa')
else
  Output ('Hupsa');

Variante B: Die Routinen erzeugen eine Exception wenn irgendwas faul ist:

Delphi-Quellcode:

Try
  EineProcedure;
  DieNaechsteProcedure;
  NochEineProcedure;
  EndlichDieLetzteProcedure;
  Output ('Alles ok');
Except
  Output ('Hupsa');
End;

Also, ich finde 'B' übersichtlicher. Das einzige, was nervt, ist das Debuggen. Aber wenn man die Prozeduren spezielle Exceptions ('EMyException') auslösen lässt, kann man die auch wegfiltern.

Aber zurück zum Thema...

ja alzaimar, das kann schon sein, aber ich hab ja geschrieben, dass das meine persönliche meinung ist mit den exceptions. ich find das einfach unschön bei sachen die man anders abfangen kann und im vornherrein bedacht hat, exceptions auslösen zu lassen.

naja muss im endeffekt jeder selbst wissen, ich finds aber schöner ohne exceptions, weil wenn nämlich dann welche auftreten, dann weiß ich bei meinem code 100 pro, dass ich da irgendwas nicht bedacht habe.

[cruso]

Noch ein Tipp um ein Programm schnell zu halten:
Möglichst wenige Timer einbauen, da zu viele Timer das Programm ausbremsen (was vor allem am Betriebssystem liegt). Also nur wenige Timer (nur einen oder wenn möglich keinen) in das Programm integrieren!

MfG
Cruso

[Jasocul]

Zitat von tigerman33:

Und Code, der mit der von dir beschriebenen Regelmäßigkeit Exceptions auslöst, macht IMHO sowieso was falsch. "Exception" heißt ja nicht umsonst "Ausnahme", und als solche sollte sie auch verstanden werden, nicht als reguläres Kommunikationsmittel. Dafür gibt es andere (schnellere!) Varianten.

Das war der Grund, warum ich schon vorher irgendwann mal geschrieben hatte, dass man die Fehlerbehandlung selbst übernehmen sollte und nicht mit Exception-Handling. Natürlich kann man es trotzdem für unerwartete Fehler verwenden. Das mache ich auch. Aber in Schleifen damit zu arbeiten und Fehler einzuplanen, um diese in einer Exception abzuarbeiten ist ungeschickt. Das ist aber ein "typischer" Anfängerfehler: "Exceptions sind Klasse. Man braucht sich um nichts mehr kümmern...".
Darum so ausführlich.

[alzaimar]

(Mein) letztes Wort zu exceptions, den Ausnahmen: Da sie ausnahmsweise auftreten, kann man die Geschwindigkeitseinbußen, die dann auftreten, ruhig in Kauf nehmen. jasoculs Code weiter oben zeigt, das eine einzelne Exception ca. doppelt so langsam wie die Abfrage per Hand ist.

Grundsätzlich ist klar, das man Exceptionbehandlung nicht zur Flusskontrolle nehmen sollte, also z.B. so (aber nicht lachen)

Delphi-Quellcode:

Done := False;
Repeat
  Try
    DoSomething;
    If Finished Then Abort;
  Except
    Done := True;
  End;
Until Done;

Nebenbei: Mein Beispielcode sollte doch nur mal demonstrieren, das der Overhead einer Try-Finally Behandlung bei ca. 20% liegt, wenn's *nicht* schiefgeht. Da man Exceptions ja für die Ausnahmen (ja Alz, das wissen wir jetzt ) verwendet, kann man die imho ruhigh im Code lassen, da es die Performance naturgemäß nur marginal beeinflusst.

Gott-Sei-Dank spielt die Programmiersprache (der alte K(r)ampf Delphi vs. C) beim Optimieren keine Rolle mehr. Nur Assembler bringt bei bestimmten rechenintensiven Geschichten noch die eine oder andere Sekunde, aber dann ist auch Schluss.

Ich kann jedem nur empfehlen, ein Gefühl für die Komplexität eines Verfahrens zu bekommen. Oben erwähntes Beispiel für die JPEG-Berechnung zeigt, das man mit 1x Nachdenken Berge versetzen kann.

Einen Punkt (ca. 10% Gewinn) hab ich noch: Rekursion vermeiden.

Ein hübsches Beispiel, wie im Team ein Problem performancetechnisch eingedampft werden kann, zeigt dieser Thread: Es ging um Primzahlen.
http://www.delphi-forum.de/viewtopic...er=asc&start=0

Hier gings um Stringkonvertierungen:
http://www.delphi-forum.de/viewtopic.php?t=46537

Und hier ums Sortieren von GB großen Textdateien:
http://www.delphi-forum.de/viewtopic...718&highlight=

So, zum Schmöckern...