Performance: mein Programm trödelt!

[NicoleWagner]

Danke für alle Antworten!
Ja, jetzt wo Ihr es sagt, AQTime war damals dabei, - doch ich kam damit nicht zurecht. Ich habe es aus meiner VM (die auch schlank sein soll) schon so lange entfernt, dass ich es schon wieder vergaß. Es kann sein, dass AQTime eher für höhere Versionen als die Pro geschrieben wurde und in der Pro zwar dabei war, doch nicht ordentlich läuft.

F7 und F8 geht bei mir eher nicht. Denn meine IDE hat Schluckauf schon seit ihrer Geburt. Delphi XE3 ist keine Glanzleistung von Embarcadero. Zuweilen müllt mir alleine die Programmierhilfe den Speicher so zu, dass ich Delphi mit dem Taskmanager abschießen muss. (Das hat jedoch wenig zu tun mit der schlechten Performance meines Programmes. Das ist fast sicher ein Programmierfehler.) Trotzdem ist F7 und F8 zu ungenau, denn das wäre dann möglicherweise der IDE-Schluckauf statt meines potentiellen Fehlers. Und F7 springt mir in den Maschinenquellcode, auch wenn ich es "einstelle", dass es das nicht tun soll ;-(
Ich arbeite in meiner Verzweiflung ersatzweise mit F4.

Ich werde zähneknirschend tun, was ich damals in Pascal tat: Eine paar globale Zeit-Variable erfinden. In der ersten wird "now" abgespeichert und danach immer wieder die Zeit (now) geholt und abgespeichert nach einem weiteren Programmschritt. "on destroy" werde ich dann subtrahieren und die Differenzen zwischen den Messungen ausgerechnet haben. Mit anderen Worten: ich speichere "now" in den globalen Vars zeit1, zeit2, zeit3,.... und sehe die jeweils vergangene Zeit.

Ein Graus in Zeiten von OOP...

[DieDolly]

Das mit den Zeitvariablen kannst du einfacher mit showmessage's machen. Bei 3 bis 4 Sekunden sieht man auch so, wo es Probleme gibt.

[Hobbycoder]

Wenn man Zeitspannen im Sekundenbereich erfassen möchte, können sich diese auch schnell aus Teilzeiten zusammenaddieren. Ob da ShowMessage wirklich immer geeignet ist, und nicht das Ergebnis zu stark verändert? Immerhin vergeht das schon die eine bis anderen 100ms bis man die weggeklickt hat.

Ich habe das dann immer so gemacht, dass ich mir als erstes eine StringList erzeugt habe, und dort mit mittels GetTickCount einen Zeitstempel und dahinter einen Text hineingeschrieben habe.
Z.B. so sl.Add(inttostr(GetTickCount) + ': OnCreate - Enter'); am Ende der Procedure so sl.Add(inttostr(GetTickCount) + ': OnCreate - Leave'); Am Ende das ganze einfach in ein temporär angelegtes TMemo oder als Datei wegschreiben.
Die eine Zeile ist schnell an die eine oder andere Stelle kopiert und angepasst und man kann sie innerhalb der Proceduren strategisch platzieren umd Rechenintensive Abläufe zu optimieren.
Hat mir immer gute Dienste geleistet.

[philipp.hofmann]

Showmessages oder klassisches Logging in ein File, geht auch mit Delphi denkbar einfach, kostet recht wenig Ressourcen und liefert immer Unmengen von Informationen, wenn man mal nicht weiter weiß. Also ich debugge 80% des Codes via Logging, weil es für mich einfach schneller geht. Ich habe dann im Code ein Info- und ein Debug-Logging, so dass in der ausgelieferten Version per Default nur das Info-Logging an ist, man kann es aber zur Laufzeit umstellen (also ein wenig das gute alte Log4J nachempfunden).

Für oftmals durchlaufende Prozeduren erfasse ich nur die Zeit und gebe am Ende des Programms dann die Summen und die Anzahl aus, damit das Logging hier nicht die Performance drückt. Auch dies läuft in einem flexiblen Singleton mit einer Liste von Key/Count/Sum-Werten, also keine globalen Variablen.

[NicoleWagner]

hier ist der Quellcode aus der Steinzeit:
Zeit - zeit9 werden verteilt ala:

zeit9:=now;

vor 'end.' steht dann:
Zeit10:=Zeit9 - zeit8;
Zeit10:=Zeit8 - zeit7;
Zeit10:=Zeit7 - zeit6;
Zeit10:=Zeit6 - zeit5;
Zeit10:=Zeit5 - zeit4;
Zeit10:=Zeit4 - zeit3;
Zeit10:=Zeit3 - zeit2;
Zeit10:=Zeit2 - zeit1;
Zeit10:=Zeit1 - zeit;

Da geht man die Werte mit F8 durch und lässt sich jweils Zeit10 anzeigen.
Wo meine Zeit geblieben ist, da bin ich noch nicht sicher. Denn Zeit 10 ist fast immer Null, bis auf eine einzige Differenz mit 2 Millisekunden. Das ist mal ein Kanditat für die Verspätung. Ansonsten werde ich die Zuweisungen noch anders verteilen.

[himitsu]

AQTime am Besten als Einzelanwendung benutzen, also sich nach dem Programmstart ans Programm hängen, bzw. die EXE vom AQTime starten lassen.
In der IDE integriert machte es bei uns, und scheinbar auch vielen Anderen, nur Probleme.

[TiGü]

Warum interveniert hier denn keiner?
Ein Debuggen ohne schrittweises Fortschreiten mit F8 und Rein springen in Funktionsaufrufe mit F7 ist doch total sinnlos.
So kann man doch nicht entwickeln!

Da solltest du nochmal Energie reinstecken, ob das Problem nicht eher woanders (Drittanbieter-Tools in der IDE) oder vor dem Gerät sitzt ("Ich weiß nicht richtig, wie man debuggt und möchte das auch nicht lernen").

Mit schrittweisen debuggen hättest du die drei bis vier Sekunden schon lange gefunden.

Das ging auch in XE3!

[Lemmy]

Zitat von TiGü:

Mit schrittweisen debuggen hättest du die drei bis vier Sekunden schon lange gefunden.

unter der Annahme, dass die genau bei einem oder vielleicht zwei Funktionsaufrufe verloren gehen sicher.

Kleine Anekdote:
Nach einem wunderbaren Vormittag vor ca. 12 Jahren brauchte meine Anwendung auf einmal mehrere Minuten, bis diese beendet wurde.
Habe lange gesucht. Selbst die ein, zwei Funktionen geprüft, die ich neu eingebaut habe. Liefen in ein paar ms durch...
Am Ende habe ich meinem Chef die 80€ für ProDel aus den Rippen geleiert, damit dauerte es ne knappe halbe Stunde das Problem zu finden (also Download, Installation, kurz über die Anleitung fliegen und anwenden). Meine tolle Funktion die 10 ms dauert wurde halt ein paar mio mal aufgerufen. Seit dem halte ich mich mit Vermutungen über "was dauert da so lange" gar nicht auf: erst messen, dann machen.

Viel geht sicher mit GetTickCOunt und Co. Bei fehlerhaften Aufrufen wird das dann (je nachdem wie man ausgibt) schon komplizierter.

Nachtrag: ein guter Logger kann hier natürlich auch helfen - Synlog das im Mormot dabei ist finde ich z.B. Klasse, das hat auch einen Viewer dabei, mit dem hätte ich das Problem oben auch gefunden (aber sicherlich mehr Zeit dafür gebraucht, weil du eben jeden Prozedureinsprung selbst mit einem Logaufruf impfen musst...

[Andreas13]

Zitat von NicoleWagner:

... Trotzdem ist F7 und F8 zu ungenau, denn das wäre dann möglicherweise der IDE-Schluckauf statt meines potentiellen Fehlers. Und F7 springt mir in den Maschinenquellcode, auch wenn ich es "einstelle", dass es das nicht tun soll.

Kann es sein, daß Du Dein Programm nicht im Debug- sondern im Relaese-Modus kompiliert hast?
Gruß, Andreas

[Benmik]

Ich bin schon ein bisschen baff, weil ich dauernd an meinen Routinen (Grafikverarbeitung) herumbastle und schaue, ob ich sie nicht ein bisschen schneller kriege. Ich nehme dazu schlicht und einfach GetTickCount , in den seltensten Fällen QueryPerformanceCounter , und ich dachte, alle anderen täten das auch.

Meine einfachste Messvorrichtung geht so:

Delphi-Quellcode:

procedure Zeit(var GTC:Cardinal;Anzeigen:Boolean = False);
begin
  If Anzeigen
    then Showmessage('Benötigte Zeit: ' + FormatFloat('0,',GetTickCount - GTC) + ' Millisekunden.   ')
    else GTC := GetTickCount;
end;

procedure MachWas;
var GTC:Cardinal; 
begin
  Zeit(GTC);
  Sleep(100);
  Zeit(GTC,True);
end;

Die aufgebohrte Fassung, mit der ich beliebig viele Verarbeitungen auf einen Schlag erwische, egal, wo sie sich befinden, geht so (habe allerdings erst kürzlich daran herumgebosselt, Bugs sind also möglich):

Delphi-Quellcode:

procedure Zeit(Titel:string;var Txt:string;var GTC:Cardinal;ZeitEnde:Boolean = False;Anzeigen:Boolean = False);
var AnzMsec:Cardinal;
const LZ5 = #32#32#32#32#32;
begin
  // Schluss aller Zeitmessungungen, Anzeige Ergebnis
  If Anzeigen then begin
    AnzMsec := GetTickCount - GTC;
    Txt := Txt + FormatFloat('0,',AnzMsec) + ' msec';
    Showmessage(Txt);
  // Endpunkt der aktuellen Zeitmessung ohne sofortigen Beginn der nächsten Zeitmessung
  end else if ZeitEnde then begin
    AnzMsec := GetTickCount - GTC;
    Txt := Txt + FormatFloat('0,',AnzMsec) + ' msec' + sLineBreak;
  // Endpunkt der aktuellen Zeitmessung mit sofortigem Beginn der nächsten Zeitmessung
  end else if EndsText(LZ5,Txt) then begin
    AnzMsec := GetTickCount - GTC;
    Txt := Txt + FormatFloat('0,',AnzMsec) + ' msec' + sLineBreak;
    Txt := Txt + Titel + ': ' + LZ5;
    GTC := GetTickCount;
  // Beginn der allerersten Zeitmessung oder Aufruf einer neuen Zeitmessung ohne andere Messung unmittelbar davor
  end else if (Txt = '') or EndsText(sLineBreak,Txt) then begin
    Txt := Txt + Titel + ': ' + LZ5;
    GTC := GetTickCount;
  end else begin
    Showmessage('Fehler bei der Anordnung der Aufrufe.');
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
var GTC:Cardinal; Txt:string;
begin
  Zeit('procedure Zeitfresser1',Txt,GTC);
  Sleep(100);
  Zeit('procedure Zeitfresser2',Txt,GTC);
  Sleep(200);
  Zeit('',Txt,GTC,True);
  // Andere Verarbeitungen
  Zeit('procedure Zeitfresser3',Txt,GTC);
  Sleep(300);
  Zeit('',Txt,GTC,False,True);
  Application.Terminate;
end;

Während der Entwicklungszeit (also ein paar Jahre lang...) benutze ich globale Variablen für GTC und Txt, damit ich sie nicht immer deklarieren muss.