Wie "teuer" ist ein wiederholtes Create & Destroy von Objekten

[tofse]

Hallo und guten Morgen,
ich habe mal eine grundsätzliche Frage.
Aktuell programmiere ich einen Terminkalender. Die Termine sind in einer Datenbank gehalten und für die Darstellung verwende ich eine eigene, von TPanel abgeleitete, Komponente.
Aktuell gehe ich beim Laden einer Kalenderansicht so vor, dass ich alle gewünschten Termine aus der Datenbank hole und dann für jeden Termin ein Objekt von meiner Komponente erzeuge, um den jeweiligen Termin darzustellen.
Wechsel ich nun die Kalenderansicht, rufe ich zunächst für jedes Objekt .free auf und lade danach wieder die Termine, um dann erneut die Objekte zu erzeugen.

So, das als Einleitung und nun die eigentliche Frage: Wie viel Ressourcen könnte so ein wiederholtes Create und free von Objekten binden? Ich erwarte jetzt keinen Wert oder so, mir geht es nur darum, ob es sich lohnt, darüber den Kopf zu zerbrechen, oder ist das völlig unnötig...? Als Alternative könnte ich mir halt vorstellen, einmal erzeugte Objekte zu behalten und in einer extra Liste zu verwalten. Beim Neuladen der Termine würde ich dann alle Terminobjekte nur leeren und ausblenden, um sie bei Bedarf wieder aus der List o.ä. zu holen. Allerdings müsste ich dann einiges ändern, deshalb die Grundsatzfrage.

Ich hoffe, ich konnte mein Anliegen einigermaßen verständlich rüberbringen

Grüße
Christof

[Iwo Asnet]

Ich würde konsequent sauber programmieren, d.h. so wie Du es machst, hört es sich gut an.
Ein wenig Overhead hat man natürlich, wobei der Speichermanager gute Arbeit leistet.

Du könntest einen ObjectPool erstellen, also freigegebene Objekte in einer Liste parken und wenn ein neues Objekt angefordert wird, erstmal schauen, ob noch ein geparktes Objekt in der Liste ist. Aber so ähnlich macht es der Speichermanager auch, also sparst Du dir vielleicht die Konstruktorlogik.

Andererseits musst Du ein Objekt aber auch plattmachen, wenn Du es (neu) zur Verfügung stellst...

Wenn es wirklich wirklich auf Performance ankommt, und Du irgendwelche Objekte millionenfach freigibst und alloziieren willst, dann verwende vielleicht lieber (statische) Records. Aber das hast Du ja nicht.

[tofse]

Hallo,
super! Es handelt sich pro Kalenderansicht um ca. 150 Objekte. Von daher hake ich das Thema gedanklich wieder ab
Danke

[bernau]

Vor dem Problem stand ich auch mal. Erzeugen und freigeben von "normalen" Objekten geht ja sehr schnell. Sobald etwas von TCustomControl abgeleitet ist, dann dauert das ziemlich lange. Ich habe es letztendlich genau so gemacht, wie du beschrieben hast.

Die Objekte nicht freigegeben, sondern in einer Liste "geparkt" und bei Bedarf einfach wieder sichtbar gemacht.

[stahli]

Ich mache es ein etwas anders.
In einem Designer stelle ich dynamisch x Objekte dar (auch Panelableitungen).

Soll eine andere Menge dargestellt werden, nutze ich die bereits vorhandenen Panels und weise denen einfach die neuen Positionen usw zu.

Existiert ein benötigtes Panel noch nicht, wird es neu erstellt.

Sind von der vorherigen Darstellung noch Panels übrig, werden diese gelöscht. (Wenn eines davon allerdings gerade den Focus hat, muss man das u.U. gesondert behandeln um Schutzverletzungen von Windows zu vermeiden, da Windows später meinen könnte, das Control nochmal zeichnen zu müssen).

Ich denke, dass diese Verfahrensweise etwas flüssiger wirken könnte.
Create und Destroy fallen sicher nicht ins Gewicht, aber die Reduzierung der Neuzeichnungen könnte sich bemerkbar machen.

[tofse]

Hallo,

danke für die Antworten. Ich habe mein Programm nun doch umgebaut. Ich merke mir die Objekte in einem Pool und greife bei Bedarf darauf zu. Ich lösche gar keine Objekte mehr, sondern die bleiben bis zum Programmende im Pool, falls sie nicht benötigt werden. Werden sowieso nicht sooo viele sein, die immer im Pool verbleiben, da in diesem "Spezial" Kalender immer eine ähnliche Anzahl von Objekte pro Ansicht vorhanden sein wird.

Mit meinen Testdaten merke ich jetzt natürlich noch keinen Unterschied, wird sich dann aber zeigen.

Christof

[bernau]

Zitat von stahli:

Existiert ein benötigtes Panel noch nicht, wird es neu erstellt.

Sind von der vorherigen Darstellung noch Panels übrig, werden diese gelöscht.

Prinzipiell OK. Wenn die Menge der Objekte stark variiert, dann ist das "Merken in einer Liste" vorteilhafter.

[shmia]

Zusatzinfo:
Der Aufwand zum Erzeugen und Zerstören von Komponenten hat einen quadratischen Anteil.
Der Grund ist, dass jede Komponente über den Owner seinen Besitzer kennt (und umgekehrt) und bei jedem Erzeugen/Zerstören die prozedure Notification für alle Komponenten des Owners ausgelöst wird.

[Patito]

Zitat von tofse:

Mit meinen Testdaten merke ich jetzt natürlich noch keinen Unterschied, wird sich dann aber zeigen.

Zur Performanceoptimierung solltest Du Dir das ganze mal in einem Profiler anschauen, z.B. AQTime oder mit dem Sampling-Profiler von Eric Grange.

http://delphitools.info/samplingprofiler/

Dann siehst Du, ob es sich lohnt...
Mit einem vernünftigen Speicher Manager (du verwendest hoffentlich FastMM) sollten 150 Objekte eher unsichtbar sein...
Wirklich lohnen wird sich das nur wenn die Objekte im Constructor irgendetwas nicht-triviales machen (Netzwerkverbindung, Datenbankabfrage, Logging, Synchronisation über Windows-Events, ...).
Sowas gehört aber normalerweise eh nicht in einen Constructor.

[Iwo Asnet]

Zitat von shmia:

Der Aufwand zum Erzeugen und Zerstören von Komponenten hat einen quadratischen Anteil.

Vielleicht sollte Emba hier mal nachbessern, wozu gibt es schließlich Hashmaps.