✔ [C++] OOP Speicher overhead?

[FBIagent]

Guten tag,

vor einiger Zeit habe ich Etwas geschrieben um Höheninformationen von
Landschaften effizient auf platte zu speicher und wieder in den Speicher
zu holen. Das Problem was sich mir jetzt stellt ist, dass ich nicht mehr ein
paar Daten von Höheninformationen habe, sondern ein paar mehr, und
hierzu zu viel Speicher verbraucht wird. Ich weis nicht ob es daran liegt, dass das OOP design so viel overhead macht, allerdings schließe ich einen
memory leak beim laden der daten aus.

Ein beispiel:
Auf der platte liegen Höheninformationen in größe von 148 MB
Wenn das programm diese geladen hat, nuzt das Programm um den dreh
1 GB Arbeitsspeicher(Laut Vista Task Manager). Das kann ich in dieser
Größenordnung nicht nachvollziehen, da nicht mehr Daten gespeichert werden , als auch in den Daten auf Platte vorhanden sind.

Ich hänge mal ein Archiv mit dem Source an. Wäre schön wenn mir
jemand erläutern könnte, warum da so emenz viel Speicher verbraucht
wird.

http://rapidshare.com/files/249596138/GeoData.zip.html

 

[Matthias Reitinger]

Hallo FBIagent,

leider lässt sich der Quellcode nicht kompilieren, da eine Datei fehlt:

GeoEngine.cpp:4:30: Fehler: ../../Utils/Math.h: No such file or directory

Grüße, Matthias

 

[FBIagent]

Ich wusste doch das ich etwas vergessen habe... Hier die fehlenden dateien.

Musst halt nur den include pfad anpassen.

EDIT:
Ich habe es auch mitlerweile auf verschiedene Weisen neu geschrieben wobei
ich beim rewrite kein OOP verwendet habe. Diese versuche haben mir gezeigt,
dass es nicht am OOP overhead gelegen hat. Ich vermute das es daran liegt,
das ich zu viel gebrauch von Zeigern mache? Wenn ich mich richtig entsinne
entspricht ein Zeiger 4 bzw. 8 byte auf 64-bit basis + die größe des datentyps.

Wenn ich davon ausgehe, das ich 67108864 Zellen in der Welt habe,
und jede Zelle einen Pointer verwended sind das 256 MB overhead, beim Flat Zellen.
Wenn ich jetzt noch die multi- und layer Blöcke hinzuzähle die ein Array
auf 8 Zeiger beinhalten wird mir da ein klein wenig übel.

 

[Matthias Reitinger]

EDIT:
Ich habe es auch mitlerweile auf verschiedene Weisen neu geschrieben wobei
ich beim rewrite kein OOP verwendet habe. Diese versuche haben mir gezeigt,
dass es nicht am OOP overhead gelegen hat. Ich vermute das es daran liegt,
das ich zu viel gebrauch von Zeigern mache? Wenn ich mich richtig entsinne
entspricht ein Zeiger 4 bzw. 8 byte auf 64-bit basis + die größe des datentyps.

Wenn ich davon ausgehe, das ich 67108864 Zellen in der Welt habe,
und jede Zelle einen Pointer verwended sind das 256 MB overhead, beim Flat Zellen.
Wenn ich jetzt noch die multi- und layer Blöcke hinzuzähle die ein Array
auf 8 Zeiger beinhalten wird mir da ein klein wenig übel.

Ja, darauf bin ich nach kurzer Analyse des Quelltextes auch grade gekommen. Den einzigen Overhead, den du durch OOP hast, sind die Zeiger auf die vtable für jede Instanz einer Klasse mit virtuellen Methoden (also i.d.R. 4 bzw. 8 Byte pro Instanz). Bei sehr vielen kleinen Objekten könnte das schon ins Gewicht fallen. Ich würde aber sagen dass sich durch die Optimierung deiner Datenstrukturen mehr rausholen lassen könnte.

Grüße, Matthias

 

[FBIagent]

Wenn ich nichts vergessen habe, bin ich mir ziemlich sicher, dass es an
der Objekt erstellung für Zelle und Blöcke liegt.

Was ich bis jetzt weis:
Der OOP mehrverbrauch lag bei 100 MB - 150 MB.
Mit auskommmentierter Objekterstellung ist der Speicherverbrauch normal.

EDIT:
Nochmal OOP entfernt und wie erwartet ist OOP nicht der Draziher gewesen.
Einmal mit gcc Kompilieren... ich bin ja jetzt wirklich baff das ein Objekt wirklich
so viel verbraucht.


In wie fern sollte ich denn die Datenstrukturen noch optimieren. Die Strukturen
beinhalten ja schon die wenigst möglichen Informationen mir fällt da nichts mehr zu
Optimieren ein.

 

[FBIagent]

Nach hin und her bin ich zu dem Ergebniss gekommen, dass der einzige Weg
um den Speicherverbrauch genug zu reduzieren darin besteht, die
Objektorientierung(es liegt ja nicht wirklich an OOP, sondern an den vielen
Zeigern) bis zur Zellenebene aufzuheben und jede Zelle einen char
buffer zu geben, den ich immer wieder zur Laufzeit analysieren muss. Mindert
die Geschwindigkeit des Codes sicherlich um einiges, was sich allerdings
nicht vermeiden lässt, da nicht jeder Server 10 GB RAM und mehr zur
verfügung hat.