Performance Messung der Unit-Initialisierungsphase

[HeZa]

Hallo,

um die Startzeit einer Anwendung bis zum Erzeugen der ersten Form zu analysieren, suche ich nach einem allgemeinen Weg, die Zeit jeder einzelnen Unit im Initialisierungsteil zu messen. Insbesondere auch für Delphi und 3rd-Party Bibliotheken.

Hat das schon Mal jemand gemacht?

Ciao HeZa

[ULIK]

Wie wäre es ganz simple mit Logging eines Timestamps? Die Initialisierung des Loggings als allererste Unit einbinden ins Projekt und dann in den jeweiligen Initialisierungsabschnitten die differenzen der TimeStamps loggen?
Oder man verwendet Profiler für so etwas (z.B. AQTime)

[HeZa]

Es sind ca. 2100 Units, davon 850 eigene. Insbesondere im Source der Delphi und 3rd-Party Units möchte ich nicht rumfummeln.

Gab es oder gibt es nicht von AQTime eine Version die man als Delphi-User ohne weitere Lizenzkosten nutzen konnte?

[ULIK]

Was willst Du eigentlich genau erreichen? Die wenigsten Units werden beim Start in Initialisierungsteil etwas stehen haben und wenn dann eher kurze Sachen. Wenn der Start der Anwendung zu lange dauert, dann schau erst mal in deine eigene Units rein, was die so treiben.
Beschreib doch einfach mal, was dein Problem ist. Ich habe auch mit der Startzeit einer Anwendung zu kämpfen und die Erfahrung lehrt, daß das Problem meist nicht da ist, wo man meint.

Was AQTime betrifft: es gab zumindest mal eine reduzierte Version mit Delphi. Ob die allerdings auch Initialisierungsbereiche messen kann, weiß ich nicht. Wenn's wirklich kritisch ist, dann ist auch der Preis von AQTime zu verschmerzen (auch wenn ich deren Lizenzmodell jetzt auch ned so toll finde).

[Uwe Raabe]

Die einzelnen initialization Abschnitte der Units werden von der Prozedur InitUnits in System.pas aufgerufen. Dort könntest du mit dem Debugger ja mal auf die Suche gehen.

Ein generelles Timing dieser Aufrufe ist aber wohl nicht so einfach möglich. Ich würde auch eher in den eigenen Units nach Problemen suchen.

[TurboMagic]

Zitat von HeZa:

Es sind ca. 2100 Units, davon 850 eigene. Insbesondere im Source der Delphi und 3rd-Party Units möchte ich nicht rumfummeln.

Gab es oder gibt es nicht von AQTime eine Version die man als Delphi-User ohne weitere Lizenzkosten nutzen konnte?

Ja, die gab es zumindest mal.
Evtl. gibt's auch eine Demo Version die man mal kurz ausprobieren könnte.

[stahli]

AQTime Pro hat den Vorteil, dass man das Tool extern außerhalb Delphi nutzen kann (seine Anwendung also innerhalb AQTime analysiert, ohne Delphi laufen zu haben).

Ich fand das damals deutlich komfortabler und stabiler - also lohnenswert.

[himitsu]

Nja, ob in der IDE oder nicht.
Das einzige Problem was wir hatten, war dass innerhalb der IDE öfters unerklärliche Exceptions auftraten, innerhalb der AQTime-BPLs/DLLs, selbst wenn man das Ding grad garnicht benutzte.

Auch daher ist es außerhalb der IDE wirklich um Längen angenehmer.


Im Programm selbst was machen zu wollen ist unschön.
Erstmal ist es nicht so einfach sich dort reinzuhängen (der Uwe sagte schon, wo man dazu was finden kann),
und dann muß an seinen Code auch sehr früh laden/ausführen, um sich reinzuhängen, bevor das Meiste schon durch ist. (und bei Verwendung der RTL/VCL-Packages ist das praktisch unmöglich)


Tipp: Falls du innerhalb des Programms wissen willst, dann deine EXE gestartet wurde, also zum Berechnen der Dauer, dann siehe GetProcessTimes.

[HeZa]

Hallo,

Danke erstmal für die Antworten.

Eigene Units sind bestimmt gute Kandidaten und tatsächlich gibt es auch bereits Vermutungen, aber ich hätte gerne an unsere interne Diskussion etwas mehr Substanz gebracht in Form von Messungen. Ich hatte gehofft, dass es da einen einfachen Weg gibt. So sieht es aber erst mal nicht aus. Es sei denn, es kann jemand bestätigen, dass man AQTime die Laufzeit der Initialisierungsabschnitte von Delphi-Units messen kann?

Wie gesagt treten die Probleme unter Terminalserver auf. Einiges erklärt sich durch die aktuell höhere Last, aber eben nicht alles.

Ein Verdachtskandidat der an mich herangetragen wurde ist EurekaLog in der Version 7.4.0.0 und die neuere Version 7.6.6.43 soll Abhilfe schaffen.
Ein anderer Kandidat ist CrystalNet, dass wir für eine Kommunikation mit einer DotNet Komponente brauchen. Hier ist die Vermutung, dass CrystalNet in der Startphase die ganze DotNet Umgebung Initialisiert.

Ich nehme erstmal den Tipp von Himitsu mit, die Zeit bis zum ersten Dialog via GetProcessTimes zu dokumentieren.

Ciao HeZa

[Lemmy]

Performanceprobleme mit Vermutungen zu lösen ist meist eine schlechte Idee.

Ein erster Weg kann wirklich sein, mit GetTickCount und CO Zeiten zu messen.

Ein Problem bleibt: auch wenn eine Funktion nur 3-4 ms für einen Lauf braucht, kann die am Ende für eine extrem lange wartezeit verantwortlich sein, wenn die entsprechend oft aufgerufen wird.

Ich verwende bei solch nicht trivialen Dingen sehr gerne http://www.prodelphi.de/
Auch, wenn das den Sourcecode verändert - aber das ist in Zeiten SVN, git und co meiner Meinung keine Ausrede mehr. Vor allem ist ProDel mit 60-70€ echt ein Schnäppchen...