Performance Messung der Unit-Initialisierungsphase

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

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

[HeZa]

Hallo,

Zitat von himitsu:

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.

das klingt nach einem sehr interessanten Vorteil.

Ciao HeZa

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

[dummzeuch]

Zitat von himitsu:

Beim Class Desctructor genau andersrum, also am Ende des Finalization.

Ist das nicht vor dem Aufruf der finalization?

[himitsu]

Zitat von dummzeuch:

Ist das nicht vor dem Aufruf der finalization?

Glaub nicht.

Es wäre ja auch sonst etwas unpraktisch, wenn du im Finalization auf die Klasse zugreifen willst.
Ist wie beim Inherited, im Constructor macht man das zuerst und im Destructor (meistens) zuletzt.

[TigerLilly]

https://www.nexusdb.com/support/inde...q=qualitysuite

Kann ich sehr empfehlen, wenn es ums Profiling geht.

[Rollo62]

Zitat von himitsu:

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

OK, auf den zweiten Blick macht das auch mehr Sinn.
Die initialisations können ja auch wieder class procedures aufrufen, wie unten als Vorschlag,
dann wäre es gut wenn diese Klassen schon vor-construiert wären.