Aufräumarbeiten bei Anwendungsende

[Zacherl]

Halte es auch für guten Stil am Ende aufzuräumen. In der Regel passiert das doch eh "automatisch", wenn die letzte Klasse freigegeben wurde. Sollte es zumindest, wenn die Klassen selbst im Destructor für Ordnung sorgen.

[Der schöne Günther]

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?

Speicherleck-Tests sind ein guter Grund, aber das versuche ich mittlerweile eher über die Unit-Tests zu machen.


Dass die Anwendung am Schluss freundlich alle Verbindungen zumacht und Tschüss sagt, da hat der Benutzer auch nichts von (außer Wartezeit). Hmm…


Ich hätte erwartet mehr Zuspruch zu bekommen 🤔

[Uwe Raabe]

Zitat von Der schöne Günther:

Ich hätte erwartet mehr Zuspruch zu bekommen 🤔

Ich vermute mal, daß das Problem mit der Wartezeit vielleicht nicht so weit verbreitet ist.

[Whookie]

Ich kann mich dem nur Anschließen, mit übermäßiger Wartezeit beim Programmende hatte ich nur selten zu kämpfen. Mit Programmen die am Ende Daten leaken habe ich aber noch nie positive Erfahrungen gemacht (allein deshalb ist meiner Meinung nach, beim Programmende alles korrekt freizugeben).

Ob sich bei einem Stromausfall oder Crash das Betriebssystem nun wirklich um alles kümmert spielt daher für mich kaum eine Rolle und aus meiner Erfahrung würde ich sage: "Mal so mal so"

[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 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 (TList.Remove bzw. 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 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.

[CCRDude]

Zitat von Neutral General:

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