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

[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 ) ist das ganze schon viel schöner und besser erweiterbar

[jensw_2000]

Bitte entschuldigt mal eine unqualifizierte Frage zwischendurch ...

Wie kann ich das
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

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

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


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

Danke

[Robert_G]

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

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