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... ;)

[sakura]

Zitat:

Zitat von 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?

Okay, dann aber wieder als Klasse und nicht als Array :zwinker:

...:cat:...

[Nogge]

Robert_G, du magst vllt sehr vertraut mit Delphi zu sein, aber ich versteh gerade kein Wort...Kann mir das jemand detailierter, "deutscher" erklären?^^
Und mein Freund schreibt lieber 5mal dasgleiche in seinen Code, als einmal in eine Procedure...

[barf00s]

www.delphibasics.co.uk

[BlackJack]

Zitat:

Zitat von Nogge

Und mein Freund schreibt lieber 5mal dasgleiche in seinen Code, als einmal in eine Procedure...

das ist schön blöd.
1. wenn er dann was ändern muss muss er es 5x ändern
2. benötigt das rund 4 mal so viel speicher wie eine procedure
3. ist das einfach nur doof.

[jbg]

Zitat:

oder weil TList aus polymorpher Sicht relativ unbrauchbar ist, da man die grundlegenden Methoden (Add, ...) nicht überschrieben kann um type safety zu forcieren?

Dann erklär mir mal, wie du eine virtuelle Add Methode überschreiben würdest, bei der sich der Parametertyp ändert? Da habe ich lieber eine statische Methode, bei der ich beim Ableiten nicht laufend reintroduce schreiben muss.

[Nogge]

@BlackJack: zu 2.: Stimmt das wirklich? Weißte das 100%ig? Hört sich irgendwie unlogisch an...

[Speedmaster]

Zitat:

Zitat von Robert_G

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

Wozu gibt es den Befehl const oder den Befehl var?

[barf00s]

das passt jetz hier nich, speedmaster :)

[BlackJack]

Zitat:

Zitat von Nogge

@BlackJack: zu 2.: Stimmt das wirklich? Weißte das 100%ig? Hört sich irgendwie unlogisch an...

jop. sagen wir der fragliche code ist 200 byte gross. 5x einzeln den code schreiben: 1000 bytes.

1x den code in eine procedure schreiben: 200 byte + ~10 byte overhead (stackframe, lokale variablen, ret)
5x diese procedure aufrufen: 5x call: ~25 byte.
dann noch ein paar bytes die benutzt werden um die parameter zu übergeben, dann kommen wir zusammen auf gut 250 bytes. also nur 1/4 des platzes, als wenn man 5x die anweisungen einzeln eintippt.

[barf00s]

reintroduce; ist nur um die _warnung_ des compilers zu unterdrücken -
ANsonsten könnte man sich des "Adapter" Entwurfsmusters bedienen und sich soo seine liste umbaun - ach was erzählich überhaupt .....

[neolithos]

Zum Thema Speicher:

Ob man es mit Objekten oder Records macht ist vom Kosten/Nutzen Verhältnis schnell geklärt -> Objekte.

Objekte:
- sind intern eh nur Records
- haben nur minimalen Overhead für Laufzeittypen und Virtuellen-Methoden.
- bringen aber viele Vorteile mit sich (Methoden, Kapselung & Co)

Der Einwurf mit CONST und VAR, war völlig berechtigt. Denn durch diese zwei Schlüsselwörter werden Zeigerübergaben relalisiert. procedure Set(a : recordtyp); heist das der Gesamtespeicher für a als Kopie auf dem Stack abgelegt werden.

Desweiteren wird durch einem Prozess reservierter Speicher nur spärlich wieder freigegeben. Dies wird u.a. nur durchgeführt, wenn man eine Anwendung minimiert oder RAM ausgelagert werden soll. Das Programm kann dies durch SetProcessWorkingSetSize steuern. Aber vorsicht diese funktion kann die Programmlaufzeit beeinflussen.

Weiterhin hängt die spätere Größe von deinem Programm von dir hab. Wie gehst du mit Variablen (spez. String und Objekten) um.

Viel Speicher spart man auch, wenn man auf Verschiedene Methoden der VCL verzichtet (Forms, Controls, usw.) und dafür lieber mit der direkten WinAPI handiert. Classes braucht man nicht unbedingt elimienieren. Da von dieser Unit wenig Import-Abhängigkeiten ausgehen. TList ist übrigens ne tolle Sache und meine Meinung nach tut es nicht weh mal ein Reintroduce zu schreiben.

Übrigens: Es macht ab und zu schon sind Code mehrmals zu kopieren (aus laufzeitspezifischen Gründen), was ich aber bei Anfängern noch nicht sehen möchte, da die Differenz bei den heutigen und alten Rechner im normalen Programmablauf nicht zu spüren ist. (außer man schreibt tolle superschnelle ausgeklügelte Algorithmen).

Für eine genaue Analyse müsste man das Programm (Quellcode) sehen. Denn bei sowas muss man auf alle Fälle kosten/nutzen-Rechnungen durchführen. Sonst kommt man heutzutage in teufelsküche.

*puh* seit langem mal wieder einen Betrag gepostet

[Nogge]

@BlackJack: Ich dachte immer nur, dass die Zeilenanzahl (wenn überhaupt) die Größe der *.pas, *.exe ausmacht. Ersetzt der Compiler nicht einfach die Stellen im Source Code, wo die Procedure steht, mit dem in der Procedure enthaltenen Code?

@neolithos: Ich habe mir folgende "Datenbank" erstellt:

Delphi-Quellcode:

type
  TUserDB = record
    UIN        : Cardinal;
    Nick       : ShortString;
    ItemID     : HTreeItem;
    UserID     : Word;
    FormIndex  : Integer;
    Msg        : String;
    Status     : Cardinal;
    { -- Hint Infos -- }
    Port       : Word;
    InternalIP : String[15]; // TCP/IP v6 wird noch nicht unterstützt
    ExternalIP : String[15]; // TCP/IP v6 wird noch nicht unterstützt
    OnlineTime : TDateTime;
    Idle       : Word;
  end;

var
  UserData : array of TUserDB;

[jfheins]

Frag mal Robert_G, aber das ist schon mal etwas "schöner" und manchmal auch effizienter (wenn statt records nur Pointer umhergeschoben werden)

Delphi-Quellcode:

 TUserDB = class
published
    property UIN: Cardinal read FBlaBlaBa write FBlaBlaBla; 
    property Nick       : ShortString read FBlaBlaBa write FBlaBlaBla;  
    property ItemID     : HTreeItem read FBlaBlaBa write FBlaBlaBla;  
    property UserID     : Word read FBlaBlaBa write FBlaBlaBla; 
    property FormIndex  : Integer read FBlaBlaBa write FBlaBlaBla;  
    property Msg        : String read FBlaBlaBa write FBlaBlaBla; 
    property Status     : Cardinal read FBlaBlaBa write FBlaBlaBla; 
    { -- Hint Infos -- } 
    Port       : Word; 
    property InternalIP : String[15] read FBlaBlaBa write FBlaBlaBla;  // TCP/IP v6 wird noch nicht unterstützt 
    property ExternalIP : String[15] read FBlaBlaBa write FBlaBlaBla; // TCP/IP v6 wird noch nicht unterstützt 
    property OnlineTime : TDateTime; read FBlaBlaBa write FBlaBlaBla;  
    property Idle       : Word read FBlaBlaBa write FBlaBlaBla;  
  end;

Dann noch mit einer Typed ObjectList (CodeLib) oder vielleicht auch der DPCollection (auch wenn ich noch nicht ganz weis, was das ist :duck:) ist das ganze schon viel schöner und besser erweiterbar ;)

[jensw_2000]

Bitte entschuldigt mal eine unqualifizierte Frage zwischendurch ...

Wie kann ich das

Delphi-Quellcode:

Setlength (Array, length (Array) + 1)

anders lösen

Ich habe in einer DB-Import-Routine 3 Arrays verbaut die die ich jeweils mit SetLength(Array, length (Array) + 1) erweitere und mit SetLength(Array, 0) wieder leere. Wusste garnicht das man das auch anders machen kann.

Bei größeren Importen (20 bis 30 Tausend Datensätze) ist bei meinem System (1GB RAM + 1,5GB Auslagerungsdatei) Schicht. Wenn ich nichts weiter offen habe packt das Programm den Import. In der Regel läuft die Auslagerungsdatei voll und der Rechner bootet :oops:

Da sonst alles super funktioniert und die Konvertierungs- und Prüfroutinen vor dem Import recht komplex sind habe ich mich bisher auch immer davor gedrückt die unit umzubauen.


Danke,
Jens

[jfheins]

Du solltest z.B. immer in hunderterschritten vergrößern. Siehe Hier

[alcaeus]

Moin Jens,

Robert_G hat mal was von einer Vergroesserung um 130% gesagt, welche optimal sein soll. TList hat dieses Verhalten AFAIR schon implementiert, also muesstest du da nur ein paar Kleinigkeiten umschreiben. Ansonsten muesstest du mit 2 Zaehlern arbeiten: einer der weiss, wie viele Elemente effektiv im Array stehn, und einer der weiss, wie viele Elemente das Array bietet. Sobald der erste Counter gleicht gross wie der zweite ist, vergroesserst du das Array wieder, usw. ;)

Greetz
alcaeus

[jensw_2000]

@alcaeus
Das ist zu bewältigen .. :thumb:

@jfheins
Danke für den interessanten Link. Und wieder ein bisschen Schlauer :angel2:


Werde mich morgen gleich mal dransetzen und die Proceduren umschreiben ...

Danke

[Robert_G]

Zitat:

Zitat von alcaeus

Robert_G hat mal was von einer Vergroesserung um 130% gesagt, welche optimal sein soll.

172% ist ein "optimales" Standardwachstum. Das kann natürlich von Fall zu Fall unterschiedlich sein.
Wenn du zum Beispiel weißt, dass du höchstwahrscheinlich nicht mehr als 10 Elemente in der Liste haben wirst, kannst du diese ja mit 10 initialisieren und somit ein späteres Kopieren verhindern. Das kann nämlich unter Umständen aufwendiger sein kann, als 3 Elemente zu viel zu reservieren. ;)

[Robert_G]

Oh eins noch...
Wenn du viele Objekte am Stück erzeugst, freigibst und wieder erzeugst, würde ich dir den FastCoder's Memory manager (FastMM) oder den NexusMM empfehlen.
Ich selbst haben den Nexus und selbst mein altes D7 läuft nun besser und schneller als vorher :zwinker:
In der BASM Group in den Borland NGs findest du einen Benchmark Vergleich aller bedeutenten MMs. Eigentlich ind fast alle besser als der, der bei Delphi normalerweise benutzt wird.

[jensw_2000]

*Freudetränen* :drunken:

Ich konnte die Gesamtelemente der Arrays vorher auszählen und das Array in einem großen Block dimensionieren.
Da wäre ich nie drauf gekommen ...

Resultat: Bei 40000 Datensätzen 300 MB RAM und 350 MB Auslagerungsdatei ...

Das klingt zwar immer noch recht hoch, aber im Vergleich zum Ausgangspunkt ist das eine enorme Verbesserung.

Jetzt muss ich nur noch dem SQL-Server während des Imports das cachen abgewöhnen und dann ist alles im grünen Bereich. Aber das ist ein anderes Thema.



Danke euch allen.

Schöne Grüße,
Jens

:hi:

[Robert_G]

Zitat:

Zitat von jensw_2000

Resultat: Bei 40000 Datensätzen 300 MB RAM und 350 MB Auslagerungsdatei ...
Das klingt zwar immer noch recht hoch, aber im Vergleich zum Ausgangspunkt ist das eine enorme Verbesserung.

Das klingt wiklich hoch...
Hast du dir mal ausgerechnet, wieviel es theorhetisch sein *sollte*.?
Speicherfragmentierung ist ein ernsthaftes Thema. Bevor ich auf den .Net Zug gesprungen bin (und bevor ich den NexusMM kannte ;) ) hat mich das doch sehr häufig erwischt.
Gerade wenn es darum ging wenig normalisierte Eingangsdaten aufzubereiten und auf zig Tabellen aufzuteilen.[1]
Da das bei 40.000 Zeilen zulange dauern würde, hatte ich es immer in speichergerechte Häppchen aufgeteilt, welche auf einem Multi-CPU und/oder HT P4 auch (in Grenzen) gleichzeitig aufbereitet werden können. :)


[1]In der Pre-XML-Zeit war es nicht ungewöhnlich, dass Eingangsdaten so übel strukturiert ankamen, dass ich eine "Zeile", nomalisiert, in 40 Tabellen und mehr packen musste/konnte.

[BlackJack]

Zitat:

Zitat von Nogge

@BlackJack: Ich dachte immer nur, dass die Zeilenanzahl (wenn überhaupt) die Größe der *.pas, *.exe ausmacht. Ersetzt der Compiler nicht einfach die Stellen im Source Code, wo die Procedure steht, mit dem in der Procedure enthaltenen Code?

nene, der code der proceduren steht nur ein mal in der exe, und dieser code wird dann immer aufgerufen, wenn die procedure benutzt wird. spart halt bei vielen aufrufen enorm platz. wenn der platz keine rolle spielt, sondern eher die performance, dann hat z.b. C++ (und ich glaube seit neuestem auch Delphi2005) die möglichkeit, inline-proceduren zu deklarieren, die werden dann tatsächlich immer im source eingefügt. spart halt jedes mal den aufruf (sind aber nur pro aufruf eien handvoll CPU-zyklen gespart).
allerdings habe ich damit unter delphi schlechte erfahrungen gemacht - nur weil der compiler das zulässt muss es noch lange nicht heissen dass es dann auch ohne abstürze funktioniert (war bei mir zumindest so).

[Jens Schumann]

Zitat:

Zitat von BlackJack

Zitat:

Zitat von Nogge

Und mein Freund schreibt lieber 5mal dasgleiche in seinen Code, als einmal in eine Procedure...

das ist schön blöd.
1. wenn er dann was ändern muss muss er es 5x ändern
2. benötigt das rund 4 mal so viel speicher wie eine procedure
3. ist das einfach nur doof.

Das muss nicht unbedingt blöde sein. Wie immer gibt es für sehr spezielle Fälle auch Ausnahmen.
Z.B. Nimm Dir einen Algorithmus und trimme den auf Geschwindiglkeit. D.h. das einzige was zählt ist die Geschwindigkeit. Wenn der Code, den Du in einer function oder procedure hast, innerhalb des Algo in einer oder mehreren Schleifen läuft kann es durch aus sinnvoll sein den Code direkt in den Algo zu schreiben. Auch wenn dies mehrfach der Fall sein sollte. Dann fällt der procedure Aufruf weg. Das kann die Geschwindigkeit des Algo entscheidend erhöhen.
Je öfter die Schleifen durchlaufen werden desto höher ist der Geschwindigkeitsgewinn.

[jensw_2000]

@Robert_G
Ich werde den zu erwartenden Speicherzuwachs nach meinem Urlaub durchrechnen.
Testweise werde ich den SQL-Server auch mal auf eine andere Maschnine auslagern, da
der sich während des Imports auch eine Menge Speicher greift. Der tatsächliche Speicherzuwachs ist sonst rechr schwehr zu bestimmen.

Generell habe ich den Import ohnehin schlecht gestaltet, weil immer jeweils ein Datensatz ausgelesen, geprüft, normalisiert und dann in dir DB geschrieben wird. Beim Schreiben in die DB prüfen sie Stored Procs auch noch ein paar Dinge ab. Ein Bulk Insert der normalisierten Daten sollte da deutlich effektiver sein.

Heute gehe ich da aber nicht mehr bei. Mein Flieger geht um 2:15 Uhr :dancer:

Danke,
Jens

[Nogge]

Zusammenfassend:
@BlackJack: Also spare ich durch Procedures (bei mehr als einem Aufruf) definitiv Festplattenspeicher (was mir eigentlich egal ist) und RAM-Verbrauch (worum es mir die ganze Zeit geht)?

Ich möchte außerdem nichts ableiten oder weitere Methoden nutzen, ich will lediglich einen schnellen Zugriff auf meine Daten im record (s. paar Posts davor) und (das wichtigste!) eine geringe Beantspruchung des RAM durch mein Programm.

[BlackJack]

@Jens Schumann:
dass man da zwischen geschwindigkeit und speicherbedarf abwägen kann, war mir schon klar (soetwas hatte ich ja gestern nacht noch gepostet), nur wenn Nogge schreibt, dass sein Freund grundsätzlich immer den code 5x schreibt statt eienr procedure, dann wird man doch wohl leise zweifel andeuten dürfen, nicht wahr? ;)

@Nogge: so ungefähr könnte man das sagen. wobei auch die RAM-belastung keine rolle spielen dürfe, wenn du nicht proceduren mit mehreren tausend zeilen "auslagerst" - auf die paar kb kommt es auch nicht an.
wobei noch zu erwähnen ist, dass du es sehr viel schwerer hast, deinen code zu warten oder zu erweitern, wenn du ohne proceduren arbeitest - hast du eine procedure, musst du den code nur einmal ändern, benutzt du keine proceduren, musst du überall in deinem projekt suchen, wo du den fraglichen code benutzt, und den dann ändern. und gross eine andere möglichkeit hast du ja nciht, da inline-proceduren wie gesagt erst ab Delphi2005 unterstüzt werden, und das auch (meiner meinung nach) mehr schlecht als recht.

aber ich würde dir wirklich raten, so viel wie möglich mit mehreren kleinen, übersichtlichen proceduren statt mit riesigen code-batzen, die du wauch noch mehrmals im code verwendest, zu arbeiten. die von Jens erwähnten geschwindigkeitszuwächse dürften erst ab mehreren millionen oder millarden proceduraufrufen in extrem zeitkritischen anwendungen ins gewicht fallen - wie gesagt braucht ein (moderner) Processor, um eine procedure aufzurufen und nachher wieder zum ursprungsort zurückzukehren, keine 10 takte.