Speichernutzung: array of record vs. TObject (TList usw.)

[Nogge]

Hallo Community,
Ich möchte gern mein Programm optimieren, d.h. CPU-Auslastung und RAM-Nutzung soweit wie möglich verringern. Ein Freund von mir hat sich ein ähnliches Programm gebastelt, benötigt aber manchmal nur 1/3 meiner RAM-Nutzung. Ich habe schon dynamisch erstellte Forms eingebaut und arbeite anstelle von TObjects und TLists mit arrays of records. Ich habe schon gemerkt, dass ich ca. 10mal so viele Procedures und Functions benutze (wird mir sonst zu unübersichtlich) als er (was wahrscheinlich der Hauptgrund ist, da diese ja vorher Speicher reservieren), trotzdem wollte ich mal wissen, ob arrays of records wirklich am wenigsten Speicher reservieren (war jedenfalls so meine Überlegung, weil diese ja Zeiger auf eine Speicheradresse setzen und nur wirklich für die Variablen des records Speicher reservieren).

[jfheins]

Wenn du dynamische Arrays verwendest: vermeide Setlength (Array, length (Array) + 1) ;)

Sonst kannst du RAM Sparen, indem du alles so früh wie möglich freigibst ;)

[barf00s]

nen einfacher pointer der _alles_ beinhaltet ist wohl das beste :)
aber du kannst _genauso_ TList und TObjectList verwenden - bei richtiger anwendung fressen die genauso speicher wie dein array of record

[Nogge]

Gibt es denn bei dem array of "Pointer" einen Unterschied im Hinblick auf den array of record?

[barf00s]

TList(&seine Freunde) kapselt ja mehr oder weniger nen array of pointer wenn'd mal in die Classes.pas schaust ...

[sakura]

Zitat:

Zitat von Nogge

Gibt es denn bei dem array of "Pointer" einen Unterschied im Hinblick auf den array of record?

Ja, es ist das Schlimmste das Du tun kannst :mrgreen: Bei Pointern geht Dir die Eindeutigkeit der hinterlegten Daten "verloren". Records sind nichts anderes als typisierte Pointer, bleibe als bitte dabei :zwinker:

Ansonsten, zum Thema Performance vs. Speicher. In den meisten Fällen sind die Typen von TList & Co. schneller und effizienter in der Nutzung und Programmierung als Records. Ein reiner Record nutzt hingegen (nur etwas) weniger Speicher als ein TList-Objekt. Aus meiner Sicht ist es dieser Speicher nicht wert die "Luxus" eines Listenobjektes nicht zu nutzen.

Records können sich allerdings auch als große Speicherfresser beweisen, wenn man, wie jfheins schon gewarnt hat, immer Dinge wie Setlength (Array, length (Array) + 1) macht :shock:

...:cat:...

[sakura]

Zitat:

Zitat von barf00s

TList(&seine Freunde) kapselt ja mehr oder weniger nen array of pointer wenn'd mal in die Classes.pas schaust ...

Richtig, aber durch die richtige Verwendung dieser (z.B. Capacity) sind diese Klassen sehr effizient. :zwinker: Und warum sollte man diese Dinge alle nochmal von Hand implementieren :wall:

...:cat:...

[Nogge]

Zitat:

Records können sich allerdings auch als große Speicherfresser beweisen, wenn man, wie jfheins schon gewarnt hat, immer Dinge wie Setlength (Array, length (Array) + 1) macht Shocked

Und wie kann man das mit den records effizenter gestalten?

[barf00s]

Oo ja wen meinst du jetz?

egal -

das mit den records - das sie kleiner als tlist items sind - ist auch nicht immer richtig - kommt ja auch auf dieses record alignment und blah blubb an

...

fazit:

solle er mit TList arbeiten - und bei klassen/objekten mit TObjectlist

[Robert_G]

Zitat:

Zitat von sakura

Und warum sollte man diese Dinge alle nochmal von Hand implementieren :wall:

Weil man dann nicht mit 5 Mio Bezeichnern aus Classes.pas erschlagen wird, bzw nicht die vcl.dcp referenziert oder weil TList aus polymorpher Sicht relativ unbrauchbar ist, da man die grundlegenden Methoden (Add, ...) nicht überschrieben kann um type safety zu forcieren?

p.s.: Habt ihr schnmal daran gedacht, dass ein Array of Record (also nicht von einem Pointer auf einen record) KOPIEN der Records enthält, die man reinwirft? -> puff jedesmal wenn du da was rausholst kostet es dich 2-mal den Speicher dieses Records bis dieser aus dem Scope rennt...

p.p.s.: Kein Wunder, dass er nur ein 10'tel der Methoden braucht. :mrgreen: Er kann Objekte voneinander ableiten und somit auch deren MEthoden. Du musst jedes Mal das Rad neu erfinden... ;)