Performance Messung der Unit-Initialisierungsphase

[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...

[Uwe Raabe]

Zitat von Lemmy:

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.

Für den Unit-Initialization Code sollte das egal sein. Der wird immer nur einmal aufgerufen.

[TurboMagic]

Zitat von Uwe Raabe:

Zitat von Lemmy:

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.

Für den Unit-Initialization Code sollte das egal sein. Der wird immer nur einmal aufgerufen.

Jein: wenn du da eine Schleife reinbaust die 1000x etwas aufruft was jeweils 3-4ms benötigt, dann geht da auch die Zeit für flöten...

[himitsu]

Ach ja, bei uns haben wir inzwischen nahezu alles "Schlimme" aus den unseren Initialization'en rausgenommen.
Stattdessen gibt es überall Class-Function ModulInitialize (in der Hauptklasse dieser Unit, bzw. des Package), die wir dann in einer zentralen Stelle der EXE aufrufen.

Erstmal hatten wir das Problem, dass wir hier massig BPLs haben und wenn es dann irgendwo hing, war es schwer zu finden.
So haben wir eine Funktion, die man "gemütlich" debuggen kann und wo sich "einfacher" eine gemeinsame Fehlerbehandlug einbauen ließ.
Unter anderem eine Fortschrittsvariable, die für die großen Zwischenschritte mit einem Namen gefüllt wird.
Einmal für die Fortschrittsanzeige beim Start und auch für den Fehlertext im großen Try-Except um alles drumrum.

Für die großen bekannten Fehlerstellen kann uns ein "Benutzer" diesen Namen am Telefon einfach nennen, ohne Eurekalog vorlesen zu müssen/können.
z.B. Acrobat zickt mal wieder rum oder das Font-Registrieren hängt mal wieder, weil MS-Office sich dämlich überall reinhängt.

[Rollo62]

Die class constructoren sind ja im Prinzip auch initialization Bereiche in einer Unit.
Wann genau werden die eigentlich aufgerufen, ich vermute mal NACH dem initialization Teil.

[himitsu]

Class Conscrutctor direkt vor dem Initialization seiner Unit, in der Reihenfolge der Deklaration der Klassen.

Hab nicht nachgesehn, ob die das über die RTTI suchen, oder ob der Compiler den Aufruf implizit in das Initialization reinschreibt.
Beim Class Desctructor genau andersrum, also am Ende des Finalization.

Aber schön am Class Constructor ist, dass es nur gemacht wird, wenn die Klasse irgendwo verwendet wurde.
Und nicht wie beim Initialization, wo der manuelle Aufruf die Klasse immer mit reinzieht, egal ob sie verwendet wird.
Deswegen, und weil Ressourcen nicht benutzungsabhängig eingebunden werden können, ist die EXE mit der VCL so rießig.