Maßnahmen zum Speicherverbrauch minimieren

[Dejan Vu]

Zitat von hstreicher:

Zitat von Mavarik:

Sagen wir mal Du nimmst dir 1GB RAM... Und willst da 200.000 Objecte unter bringen...
Dann kann jedes Object 5,2 MB groß sein...

5,2 KB , sonst wirds 1 TB Ram

LOL

Wäre es nicht denkbar, das Klassen an sich mehr Speicherplatz verbraten, als z.B. Records?

Davon unabhängig solltest Du einfach mal messen, wie groß ein Businessobjekt inklusive aller Unterobjekte ist. Dazu kannst Du dir ja einfach eine Funktion 'Size' für alle Klassen implementieren:

Delphi-Quellcode:

Function TMyObject.Size : Integer;
begin
  Result := SizeOf(FMyDouble)+StringSize(FMyString);
  For item in FMyObjectList do 
    inc(Result, item.Size);
end;

Dann hast Du schon einmal den Nettoverbrauch an Daten. Das solltest Du in der Factory machen, d.h. die Factory führt darüber Buch, wie viel Bytes es bisher produziert hat.

Wäre doch mal interessant, ob wirklich die Objekte das Problem sind, oder nicht etwas anderes.

Wie sehen deine Objekte denn in etwa aus? Müssen es Namen (String) sein, um ein Objekt zu identifizieren? Tut es ein integer nicht auch?

[stahli]

Ich habe gestern einfach mal String durch AnsiString ersetzt.

Nach Studium der Hilfe http://docwiki.embarcadero.com/RADSt..._in_RAD_Studio
war zu erwarten, dass es nicht sehr viel ausmachen wird. Und so ist es auch.
Statt 92539 Hauptobjekten konnte ich 97059 erzeugen.

Wie bereits beschrieben, sind das die Hauptobjekte, denen diverse Eigenschaften, Listen und Referenzzeiger zugeordnet sind.
Wirkliche Objekte werden viel mehr erzeugt.

Auf die Namen kann ich nicht verzichten. Aber ich könnte einen platzsparendere Stringtyp wählen. Ich weiß nur noch nicht welchen.


Ich habe gestern mal versucht, mit AQTime Pro den Speicherbedarf einer Methode zu profilen, in der eines meiner Hauptobjekte erzeugt wird.
Im Gegensatz zu dem Performance-Profile ist das aber beim Allocation-Profiler scheinbar so nicht möglich. Zumindest habe ich das gestern nicht hingekriegt.
Also werde ich das mal (wie von Dejan Vu vorgeschlagen) von meiner Factory protokollieren lassen oder das Projekt entfrachten und nur ein Mainobject erzeugen und dieses mit AQTime analysieren.

Über eine schrittweises Debuggen ist mir erst mal nichts falsches aufgefallen. Es sind halt recht viele Untereigenschaften und ich werde schauen müssen, was ich dort optimieren kann.

Ich werde mich also mal weiter Stück für Stück voran tasten...

[Sir Rufo]

Ich habe da so eine vage Vermutung, was deinen immensen Speicherbedarf verursacht.

Kannst du mal das Interface von so einem BO zeigen und wie du auf eine Eigenschaft zugreifst?

Ich vermute nämlich, dass du für jede BO Instanz die Eigenschafts-Namen als String im Speicher hast ...

[stahli]

Worauf willst Du raus?

Ich habe z.B.

Delphi-Quellcode:

IMyInf = interface
...
property Name: string read get_Name write set_Name
...

Die Klasse hält dann natürlich noch ein fName: String bzw. ein Objekt, das einen String verwaltet.

Bei Bedarf durchsuche ich eine Liste nach einem Interface mit einem bestimmten Namen. Wenn das einmal gefunden ist arbeite ich nur noch direkt mit dem Interface.

Beziehungen zwischen Objekten/Interfaces werden nicht über Namen-Strings abgebildet.

Ich kann gern mal einen Auszug raussuchen, aber es wäre gut zu wissen, wo Du ein Problem vermutest...

[Sir Rufo]

Ich vermute, dass genau diese Strings, die den Namen für was auch immer definieren, dir den Speicher vollmüllen.

Das kann ich aber erst sehen, wenn ich sehe, wie du denn mit diesen Namen in deinem BO umgehst

[BUG]

Im Prinzip: Hast du Strings (außer einem eindeutigem Namen), die du für jedes BO anlegst?
SirRufo will vermutlich auf so etwas wie Eigenschafts/Spalten-Namen hinaus, die bei vielen Objekten gleich wären.

[Sir Rufo]

Zitat von BUG:

Im Prinzip: Hast du Strings (außer einem eindeutigem Namen), die du für jedes BO anlegst?
SirRufo will vermutlich auf so etwas wie Eigenschafts/Spalten-Namen hinaus, die bei vielen Objekten gleich wären.

Das ist meine Vermutung

[jaenicke]

Wie hoch ist denn der Speicherverbrauch (z.B. auch einfach im Taskmanager, muss nicht so genau sein), wenn du die Out-Of-Memory Exception bekommst?

Wir hatten das gleiche Problem und haben daraufhin auf 64-Bit umgestellt, da es bei unserer Anwendung mit Speicher sparen nicht gereicht hätte. Dort konnte man aber einen Riesenunterschied zu dem Out-Of-Memory der Delphi IDE sehen:
Bei uns kam der Speicherverbrauch auf ca. 1,7-1,8 GiB hoch bevor es zum Problem kam.
Bei der Delphi IDE hingegen kommt (vermutlich durch ungünstiges Speichermanagement?) der Fehler schon bei ca. 1 GiB.

Wodurch wir Speicher sparen konnten war z.B. die Verwendung von TDictionary statt TStringList für die Zuordnung zwischen Strings und anderen Daten, da dadurch nur noch ein Hash im Speicher bleibt statt des ganzen Strings.

[BUG]

Zitat von jaenicke:

da dadurch nur noch ein Hash im Speicher bleibt statt des ganzen Strings.

Das halte ich für ein Gerücht: dann müsste die Hash-Funktion ja eindeutig sein und das Dictionary ließe sich nicht aufzählen.