DataSet: Speicherverbrauch berechnen

[haentschman]

Hallöle...

mein Vorhaben:
* Stapeldruck einer größeren Menge Aufträge (ca. 3000) mit verschiedenen Belegarten und unterschiedlichem Inhalt
-> verschiedene Formulare für die einzelnen Belegarten (je Belegart 1 Formular)
-> Datenumfang ungefähr wie eine normale Rechnung
-> max. 10 Positionen

meine Idee:
* einen Druck Pool (Klasse mit Liste)
* jeder Druckauftrag bekommt sein eigenes Dataset mit WHERE statt Gesamtdatenmenge mit IN Statement

Frage:
Läßt sich irgendwie der Gesamtspreicherverbrauch (Arbeitsspeicher) berechnen? Formel? Das Meiste machen die DataSets aus...denke ich. Ich hätte gern einen Anhaltspunkt bevor ich loslege... Ansonsten muß ich das Konzept überdenken.

Danke...

Crosspost: https://forum.delphi-treff.de/index....uch-berechnen/

[KodeZwerg]

Die Unit FastMM hat eine Protokoll Funktion, vielleicht hilft dir das weiter?

[haentschman]

Danke...aber nicht wirklich.
Es existiert nur ein Konzept. Noch nicht mal das SQL ist erstellt. Ich möchte nur wissen wie speicherlastig das Konzept sein könnte...die Anwendung hat eh schon zuviel.

[KodeZwerg]

Tut mir leid, da hatte ich was falsch verstanden, mein Tipp galt logischerweise nur bei bereits ausführbaren Anwendungen.

Ps: Vielleicht hast Du ja bereits ein ähnliches Projekt oder eventuell hat Delphi ein Demo-Beispiel ähnlichen Inhalts, da könnte man kurzzeitig FastMM Einbinden, Werte ermitteln und glücklich werden?!

[haentschman]

Man könnte ja die einzelnen Größen der benötigten Felder zusammenrechnen... aber ich kenne nicht den Overhead (Speicher) eines Datasets.

[himitsu]

Du gehst alle Fields des DataSets durch.

Da jeweils TField.DataSize nehmen und zusammenrechnen.
Das mit der Anzahl der Records multiplizieren (RecordCount + 2 für sowas wie TField.OldValue).
Dann nochmal alle Felder/Records mit TBlobField durchgehn und von jedem Blob einzeln die Größe dazu addieren.

Und am Ende noch bissl Offset für ungenutzte Anteile der reservierten Speicherblöcke auch noch draufrechnen (für jeden einzelnen Record und Blob) ... Speicherfragmentierung


PS: Bei CHAR(x) und VARCHAR(x) mit UTF-8 sind das oftmals 5 Byte pro Char, zuzüglich der Längenangabe für VARCHAR und einem Bit für NULL.
Und TBlob (BLOB, TEXT, usw.) sind das ein Pointer + der Speicher in Form eines TData (per Default, falls die TDataSet-Ableitung nicht was anderes/eigenes implementiert)

Längenangabe und NULL einfach ignorieren (das ist bei DataSize schon drin) und der Rest ist eh schon ausreichend ungenau genug.

[Uwe Raabe]

Zitat von haentschman:

Man könnte ja die einzelnen Größen der benötigten Felder zusammenrechnen... aber ich kenne nicht den Overhead (Speicher) eines Datasets.

Das hängt ganz von dem verwendeten DataSet ab. Allerdings sind das auch ziemlich tiefe Interna und gegebenenfalls schwer bis überhaupt nicht zu ermitteln.

Als Richtgröße kannst du aber den Vorschlag von Himitsu aufgreifen und Summe über die Spaltengrößen mit der Anzahl der im Speicher gehaltenen Zeilen multiplizieren. Wie viele das sind, hängt halt auch vom verwendeten DataSet und seinen Einstellungen ab. Wenn z.B. eine TFDQuery in den FetchOptions Unidirectional aktiv hat, werden die abgearbeiteten Zeilen immer freigegeben. In Kombination mit einer Einschränkung der RowSetSize kann man den Speicherbedarf schon in Schranken halten.

Bei anderen Datenzugriffskomponenten kann das aber auch anders aussehen.

[haentschman]

Danke...

Ihr habt Recht... Ich glaube ich mache mir einen Test mit 20 string Feldern (mit durchnittlich 100 Zeichen) und mit FireDAC mit der Anzahl der Reihen. Das sollte für die Entscheidungsfindung reichen...

[haentschman]

Sooo... Entscheidung ist gefallen. Das funktioniert nicht. Jeder Druck mußt direkt raus! Die Masse machts!

Testumgebung: Schleife ohne Freigabe (Tabelle mit 30 Feldern verschiedenster Typen ohne Blob)
Ergebnis: Memory

Fazit: Bei 500 Datasets liegt der Verbrauch bei 465MB (635 - 170 Anfang)

Schönes Wochende...

[mensch72]

Einzeln geht immer

Für unsere Software im Banken/Finanz-Bereich wo bei Abschlüssen auch mal zig Belege(auchmal 5-6stellig) zum Druck/zur Archivierung erstellt werden müssen, löse ich das per paralleler Multitask PDF-Erzeugung... Mehr Workerthreads wie doppelte CoreAnzahl lasse ich nicht zu. Das sind selbst bei 16Core-Systemen max 32 "Report-Threads" und da bleibe ich auch bei 32Bit Software noch gut im Speicherlimit.
Die letztendlich echte (Druck)Ausgabe oder Archivierung geht, überlasse ich das per Batch gerne einem Drucker(Pool)Treiber oder sonstiger Software auf dem Hostsystem.