![]() |
Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
Hallo,
meine Delphi-Applikation benötigt unverhältnismäßig viel Zeit beim Starten, das dauert je nach System bis zu 10 Sekunden, und das ohne ein Zeichen für den Anwender (z.B. Kreis/Sanduhr des Mauszeigers). Auf der Suche des Problems habe ich mit der ersten Programmzeile in der DPR-Datei bis kurz vor dem Application.CreateForm einen SplashScreen inkl. Zeitmessung eingebaut, weil auch einige Startinitialisierungen wie z.B. Kommandozeilenparameter durchgeführt werden. Die Initialisierungszeit beträgt aber nur ca. 2 Sekunden, beträgt also nicht den Großteil der tatsächlichen Ladezeit. Das Programm benötigt Admin-Rechte, die es beim Start einfordert. Das sehe ich aber nicht als Problem an, und die Zeitmessung beginnt ja erst mit der Zustimmung in der Windows-Benutzerkontensteuerung. Dann dachte ich, die Exe-Datei könnte zu groß sein (ca. 11 MByte). Daraufhin habe ich einen Runtime-Packer verwendet (ASPack, ![]() An Windows 7 x86 und Delphi XE (inkl. der neuesten Aktualisierungen) kann es meiner Meinung nach auch nicht liegen. Habt Ihr Vorschläge, wie ich dem Problem auf den Zahn fühlen kann? In welche Richtung kann man da weiter forschen? Vielen Dank. |
AW: Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
Öffnest Du eine Datenbank?
|
AW: Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
Wieviele Forms werden initialisiert?
Was passiert in den OnCreate - Behandlern? Grüße Christoph |
AW: Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
irgend welche initialization Abschnitte in den Units eingebaut? Wie viele? was passiert da?
|
AW: Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
Die 'initialization' Abschnitte werden aber gänzlich *vor* der ersten Zeile des Hauptprogramms ausgeführt. Um die Suche einzugrenzen, füge einen Breakpoint auf dem 'Begin' des Hauptprogramms ein. Starte die Anwendung.
Vergeht die meiste Zeit, *bevor* der Breakpoint erreicht wird, liegt es an einer der 'initialization' Abschnitte der Units. Stoppt die Anwendung sehr schnell am Breakpoint, liegt es an den Formularen selbst. Entweder werden sehr viele automatisch erstellt oder im OnCreate/OnShow der Formulare passiert etwas, das sehr lange dauert. Aber das wurde ja oben schon erwähnt. Um Eingrenzen einfach mal nur das Hauptformular erstellen lassen. Danach sukzessive die einzelnen Formulare erstellen, bis die Verzögerung eintritt. |
AW: Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
Die zeitintensiven Initialisierungen kann man auch als lazy load implementieren, so dass die erst beim ersten echten Zugriff erstellt werden oder auch ganz modern als
Delphi-Quellcode:
.
TTask.Future
Ob der erste echte Zugriff dann eine Sekunde dauert ist nicht so tragisch, wie eben beim Start 14 Sekunden zu warten (weil z.B. 14 Instanzen initialisiert werden die jeweils 1 Sekunde benötigen). Auch sollte man darauf achten, dass bei der Initialisierung nicht zu viel passiert und auch die Unterinstanzen als lazy load oder Future implementiert. |
AW: Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
Eventuell funkt dir da auch ein Virenscanner dazwischen...
Ich hab' sowas schon mehrfach mit Kaspersky beobachten können. |
AW: Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
Das ist doch jetzt grade alles Raterei- Kann man nicht mit Tools wie AQTime einfach schauen, was wie lange braucht? Ob der schon die Unit-Initialisierung erwischt weiß ich allerdings nicht...
|
AW: Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
Zitat:
Zitat:
Unit-Initalisierung rufen fast immer irgenwelche privaten Funktionen auf. Diese werden auf jedenfall erwischt. |
AW: Unverhältnismäßig lange Startzeit meiner Delphi-Applikation
Danke, ich werde mir mal die Unit-Initialisierungen und dann AQTime anschauen. Mal sehen, was dabei herauskommt...
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:14 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz