Aufräumarbeiten bei Anwendungsende

[sh17]

Vielleicht lässt sich der Speicherbereich, der hier anscheinend so viel Zeit in Anspruch nimmt, um bereinigt zu werden, anders organisieren??? Da müsste man nur wissen worum es geht?

[Neutral General]

Ist halt recht schwer einzuschätzen ohne genaueres zu wissen. Generell bin ich auch jemand der alles schön aufgeräumt haben will.
In der Praxis hat Raymond denke ich mal (evtl. Sonderfälle ggf. ausgeschlossen) Recht. Wenn der einzige Code der deine Anwendung noch ausführen wird bis zum endgültigen Ende das Freigeben von Speicher etc ist,
dann kann man sich diesen Code sparen. Ich hatte wie die meisten anderen hier auch noch nie das Problem, dass das Aufräumen so lange gebraucht hat, dass ich nicht-Aufräumen in Betracht ziehen musste.
Ich würde es wahrscheinlich mal probieren. Wenn der Geschwindigkeitsgewinn sehr groß wäre, dann würde ich es in Betracht ziehen.
Andererseits wäre für mich dann auch noch die Frage ob der Benutzer überhaupt (noch) etwas von der Anwendung sieht wenn diese aufräumt oder ob dann schon alle Formulare etc geschlossen sind.
Wenn das einzig sichtbare beim Aufräumen der Eintrag im Taskmanager ist, dann wird sich der User daran sicher nicht stören, denn für ihn ist das Programm aus, wenn er nichts mehr davon sieht.

Aber ist wahrscheinlich größtenteils ne Glaubensfrage, genauso wie ob man FreeAndNil bei lokalen Variablen benutzt oder nicht - Es nutzt rein gar nichts, aber für manche fühlt es sich sauberer an.

[Zacherl]

Tatsächlich hatte ich einmal eine Baumstruktur mit einigen tausend Nodes, für die alle eine Klasseninstanz im RAM residierte. Dieser Baum war recht kompliziert aufzuspannen und dementsprechend rechenintensiv war das Hinzufügen, aber auch Entfernen der Nodes (hatte kaskadierende Events mit Neuberechnungen zu Folge). Bei dieser Anwendung ist mir dann auch aufgefallen, dass das Aufräumen am Ende noch mehrere Sekunden angedauert hat. Beim Debuggen merkt man das ja recht schön, wenn zwischen dem Klick auf X und dem Umschalten auf Designtime Oberfläche in Delphi einige Zeit vergeht.

Habe mir dann auch so beholfen, dass die Klasse im

Delphi-Quellcode:

destructor

ein Flag setzt, was alle Neuberechnungen auf Eis gelegt hat und dann einfach sämtliche Nodes in einer Schleife freigibt und danach die Index-Liste löscht (

Delphi-Quellcode:

TList.Remove

bzw.

Delphi-Quellcode:

TList.IndexOf

wurde mir tatsächlich hier auch zum Flaschenhals, da die Nodes sich im Normalfall selbst (de-)registriert haben).
Das hat mir schon einen deutlichen Geschwindigkeitsboost gebracht. Hatte dann zeitweise noch überlegt

Delphi-Quellcode:

InitInstance

für meine Nodes zu überschreiben, damit ich einfach einen großen zusammenhängenden Speicherblock reservieren - und am Ende in einem Rutsch freigeben - kann. Die Idee habe ich allerdings wieder verworfen. Unter 64-Bit wäre das zwar kein Problem gewesen, da die Node-Klasse auch nicht sonderlich groß war, allerdings bestand sie aus einer Komposition mehrerer anderer Klassen, für die ich konsequenterweise das Spielchen dann auch hätte weitertreiben müssen.

[Uwe Raabe]

Zitat:

Zitat von Zacherl (Beitrag 1412133)

und dementsprechend rechenintensiv war das Hinzufügen, aber auch Entfernen der Nodes (hatte kaskadierende Events mit Neuberechnungen zu Folge).
...
Habe mir dann auch so beholfen, dass die Klasse im

Delphi-Quellcode:

destructor

ein Flag setzt, was alle Neuberechnungen auf Eis gelegt hat

In so einem Fall stelle ich mir dann immer die Frage, ob es nicht auch im laufenden Betrieb vorteilhaft wäre, die Neuberechnung nicht bei jeder Änderung durchzuführen, sondern z.B. mit einem NeedsRecalc-Flag oder einem BeginUpdate/Endupdate aufzuschieben. Dann braucht man bei Programmende nur ein BeginUpdate aufrufen und das zugehörige EndUpdate entfällt dann einfach (hier ist dann auch ein erklärender Kommentar angebracht, sonst materialisiert sich auf wundersame Weise dann in ein paar Monaten doch noch ein EndUpdate).

[freimatz]

Zitat:

Zitat von Der schöne Günther (Beitrag 1412022)

Zitat:

Zitat von Uwe Raabe (Beitrag 1412012)

Beim Destroy einer Klasse weiß ich in der Regel nicht, ob lediglich die Instanz freigegeben wird oder das Programm beendet. Ebensowenig weiß ich, was um mich herum gerade passiert.

Absolut, das kann man nicht wissen, das ein Destruktor in der Regel alles aufräumen sollte was man aufgebaut hast stellt sicher niemand in Frage ��

Nicht? Genau so habe ich Raymond aber verstanden.

Zitat:

Zitat von Der schöne Günther (Beitrag 1412040)

Vielleicht beeindruckt mich auch nur Raymond Chens anschauliches Beispiel so sehr. Ich meine, er hat ja nicht Unrecht. Welchen Sinn macht es, akribisch jedes Byte freizugeben wenn die Anwendung sowieso nicht mehr gebraucht wird?

Ja, es macht keinen Sinn alles freizugeben, wenn die Anwendung sowieso nicht mehr gebraucht wird. Aber: eben nur wenn. Wie Uwe schon schrieb, kann die Klassen das nicht (ohne weiteres) wissen ob das "wenn" nun eintritt.
Oder willst Du ein globales Flag Shutdown: Boolean einführen und in jedem destructor prüfen ob das gesetzt ist? :wink:

[himitsu]

Zitat:

Zitat von freimatz (Beitrag 1412308)

Oder willst Du ein globales Flag Shutdown: Boolean einführen und in jedem destructor prüfen ob das gesetzt ist? :wink:

Gibt es schon:

Delphi-Quellcode:

Application.Terminated

Aber so direkt in Komponenten sollte man es dann doch nicht verwenden, denn
* in einer Service-Anwendung kommt "Application" nicht aus der Unit Forms, sondern aus SvcMgr
* im FMX ist es FMX.Forms statt VCL.Forms
* In einem Thread wäre es

Delphi-Quellcode:

Self.Terminated

, falls der Thread in der RTL gekapselt wäre,
und außerhalb der Threadklasse könnte man auf die Idee kommen

Delphi-Quellcode:

TThread.CurrentThread.Terminated

zu nehmen, was aber nicht funktioniert, da CurrentThread eine "eigene" Klasseninstanz nutzt und der Terminated-Flag nicht durchgereicht wird.
* ...
und für eine Komponente/Unit ist beim Kompilieren aber nicht ersichtlich, wo sie verwendet wird.

[Zacherl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1412136)

Zitat:

Zitat von Zacherl (Beitrag 1412133)

und dementsprechend rechenintensiv war das Hinzufügen, aber auch Entfernen der Nodes (hatte kaskadierende Events mit Neuberechnungen zu Folge).
...
Habe mir dann auch so beholfen, dass die Klasse im

Delphi-Quellcode:

destructor

ein Flag setzt, was alle Neuberechnungen auf Eis gelegt hat

In so einem Fall stelle ich mir dann immer die Frage, ob es nicht auch im laufenden Betrieb vorteilhaft wäre, die Neuberechnung nicht bei jeder Änderung durchzuführen, sondern z.B. mit einem NeedsRecalc-Flag oder einem BeginUpdate/Endupdate aufzuschieben. Dann braucht man bei Programmende nur ein BeginUpdate aufrufen und das zugehörige EndUpdate entfällt dann einfach (hier ist dann auch ein erklärender Kommentar angebracht, sonst materialisiert sich auf wundersame Weise dann in ein paar Monaten doch noch ein EndUpdate).

Genau so funktioniert es intern im Grunde auch :thumb: Da wie du schon vermutest auch praktisch jede Änderung an Properties eine Neu-berechnung zur Folge hat, war eine

Delphi-Quellcode:

BeginUpdate

/

Delphi-Quellcode:

EndUpdate

Funktionalität sowieso zwingend notwendig.

[CCRDude]

Zitat:

Zitat von Neutral General (Beitrag 1412125)

Wenn das einzig sichtbare beim Aufräumen der Eintrag im Taskmanager ist, dann wird sich der User daran sicher nicht stören, denn für ihn ist das Programm aus, wenn er nichts mehr davon sieht.

Es sei denn, er fährt seinen Rechner runter, während das Programm noch offen ist. Dann bemerkt Windows, das das Programm auf die Beenden-Message nicht im vorgegebenen Zeitraum reagiert, und informiert den Benutzer darüber.

Im Rahmen der ganzen Telemtrie-Dinger dürfte MS dann auch merken, dass das Programm häufiger "nicht ordnungsgemäß" funktioniert. Wer weiß, wo das irgendwann schaden kann? Gibt ja zum Beispiel bei Windows Upgrades immer mal wieder Programme, die wegen "Inkompatibilität" mehr oder weniger still entfernt werden. Das Risiko, mit so einem nicht regelkonformen Verhalten irgendwann auf dem falschen Index zu landen, wäre mir zu groß.