Hallo, ich wollte mal errechnen, wieviel Speicher eine Instanz eines Objektes meines Projekts verbraucht (AllocMem* gibt ja den Verbrauch in Bytes an, aber nur für das ganze Projekt).
In der SuFu hab ich zu dem Titel nix sinnvolles gefunden also schreib ich es mal hier rein.

Ich hab mir überlegt das man ja viele Variablen Problemlos berechnen kann (z.B.: 2 * Integer (je 32 Bit) = 64 Bit = 8 Byte), das Problem hierbei ist nur das ich nicht weiß wieviel die Variable braucht um vom Rechner als beispielsweise Integervariable erkannt zu werden und wieviel das Objekt auch ohne Werte an sich braucht.

Ich habe als Beispiel ein Objekt von der Klasse TWettereffekt.
Diese enthält einen Zeiger auf eine Textur von der Klasse TTextur (sollten bei XP 32 Bit (und bei Vista 64 Bit?) sein), einen Boolean der mir verrät ob der Effekt überhaupt gezeichnet werden soll (sollte 1 Bit sein), Breite, Hoehe, Richtung und Geschwindigkeit vom Typ Single (laut Delphi Hilfe 4 Byte, also 32 Bit groß), hinzu kämen noch einige Prozeduren und Funktionen, die eigentlich keinen zusätzlichen Speicher pro Instanz brauchen sollten. Sollte theoretisch also 32 (oder 64) + 1 + 4 * 32 sein, also insgesamt 161 Bits sein, oder?

Doch was ist der wirklich Wert?

AllocMem alloziert Speicher und gibt nicht den verbauchten Speicher der Anwendung zurück. Ein Boolean braucht zwar theoretisch nur 1bit, aber praktisch sind
es mehr und zwar zwischen 1 byte (Boolean) und 4 byte (LongBool).

Eine Klasse braucht aber auch zusätzlich Speicher, es wird sogar der Klassenname im Speicher gehalten.
Den Speicherverbrauch einer Klasseninstanz bekommt man mit .InstanceSize().

Danke für die Hilfe, es funktioniert vollkommen Problemlos.

(>*Bearbeitet*<)
Leider habe ich ein Problem festgestellt. Wie erhalte ich den Speicherbedarf INKLUSSIVE des Bedarfes der dynamischen Stringvariablen?
Ich habe es mit einem String getestet der testweise 255 Zeichen enthielt aber immernoch denselben Bedarf hatte als wenn er 0 Zeichen lang wäre (im übrigen unter 255 Byte Bedarf ---> er wird nicht einberechnet).

Ich hab mal folgende Aussagen und Gleichungen aufgestellt. Wenn sie wer bestätigen oder korrigieren könnte, dann wäre das sehr nett.

Eine Instanz der Klasse TKarte ist 152 Byte (=1216 Bit) groß, hinzukommen noch der Speicherbedarf der String-Variablen „DateiName“ und „ProjektPfad“, die einen dynamischen Speicherbedarf haben.
Eine Instanz der Klasse TFeld ist 32 Byte (=256 Bit) groß, hinzu kommt noch der benötigte Speicher für die Textur im Grafikkartenspeicher selbst.
HIERBEI MÖCHTE ICH ERWÄHNEN DAS TFELD 6 ZEIGER AUF ANDERE FELDER HAT (3 Dimensionen und in jede Dimension 2 Richtung), dies ist für die Rechnung weiter unten wichtig.
Eine Instanz der Klasse TTextur ist 28 Byte (=224 Bit) groß, hinzu kommt noch ein dynamischer Speicherverbrauch durch den Namen der Textur.
Eine Instanz der Klasse TObjekt ist 44 Byte (=352 Bit) groß.
Eine Instanz der Klasse TWettereffekt ist 28 Byte (=224 Bit) groß. Pro Karte existieren immer genau 4 Instanzen dieser Klasse, daher beträgt der Speicherbedarf 4*28Byte (=112Byte =896Bit).
(Sämtliche größen wurden mittels INSTANCESIZE() ermittelt).

Als Beispiel für eine Anwendung sei folgendes gegeben: die Karte enthält 70 Texturen, ist 50x50 groß und enthält 5 Schichten, hinzukommen noch 100 Objekte. Der Verbrauch der String-Variablen wird nicht beachtet. Die Karte selbst verbraucht 152 Byte und es sind 4 Wettereffekte immer vorhanden, das macht 112 weitere Byte Speicherverbrauch. Das sind damit 264 Byte fester Speicherbedarf. Die 70 Texturen verbrauchen 1960 Byte im Arbeitsspeicher. Die Karte enthält 50*50*5 Felder, was 50*50*5*32 Byte Speicherbedarf verbraucht, also insgesamt 400.000 Byte. 100 Objekte benötigen 4400 Byte.
Insgesamt verbraucht diese Karte also für ihre Instanzen 406624 Byte (=397,09375 kByte), das Programm würde aber zur Laufzeit viel mehr verbrauchen, da die dynamischen Variablen nicht mit einberechnet wurden, die Texturen im Grafikkartenspeicher missachtet wurden und der Verbrauch des restlichen Programms noch fehlt. Man könnte Speicherplatz einsparen indem man beispielsweise bei der TFeld-Klasse die Zeiger auf andere Felder entfernt und stattdessen ein dynamisches Array verwendet, dies hätte allerdings den Nachteil, das man nicht mehr so leicht neue Feldreihen einfügen könnte. Würde man dies tun, so würde ein Feld nur noch 8 Byte (=64 Bit) einnehmen und der Verbrauch von 50x50x5 Feldern würde nur noch 100.000 Byte, also ein Viertel betragen. Der Gesamtverbrauch wäre also 106624 Byte (=104,125 kByte).

Wieso ist dir der Speicherverbrauch denn so wichtig, das sind doch nur ein paar kB? Das alles auszurechnen scheint doch ein bisschen sinnlos?!



Was soll das bringen? Ein Pointer ist 4 ( oder 8 ) Byte groß, die Ersparnis wäre doch eher gering.

Also, was ich verstehen könnte wäre, wenn du so wie ich das ganze nochmal auf 100 Planeten hast. Aber da das nicvht der Fall ist... Ich glaube, die paar KB kann man verkraften. Rechner haben heutzutage mehrere Gigabyte an Speicher, ich sehe da wirklich kein Problem. Eine Anwendung kann auf 32 bit bis zu 2GB Ram bekommen, mit irgendeiner komischen Erweiterung auch 4GB(geht aber glaube ich nur unter Linux, keine Ahnung). Wenn sie auf 64-bit läuft sind es ....... viele, viele GB, die du theoretisch allozieren kannst. Nebenbei auch noch die komplette Festplatte als Auslagerungsdatei .

Insofern würde ich mir da keine Sorgen machen. Aber sich darüber gedanken zu machen ist wichtig. Schließlich will das ganze auch mal in eine Datei zum Speichern oder so und da ists dann doch etwas anders. 400MB Savegame will glaube ich keiner . Aber das ist ja bei dir nicht erfüllt.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

fein fein, .InstanceSize(), wieder was gelernt *g*.

Aber Markus hat Recht, dein obiger Speicherverbrauch hält sich wirklich arg in Grenzen. Es sei denn, du willst das irgendwie auf einem µC laufen lassen, das bezweifel ich aber mal . Da würde ich lieber woanders optimieren...

Edit: Horazont, unter Windows gehen auch 3GB mit dem entsprechenden Parameter in der boot.ini

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Naja, er möchte es einfach wissen, oder? Das ist grundsätzlich ja sogar einer der wichtigsten Kapitel beim Programmieren. Find ich GUT, dass er das wissen will. Wenn man sich hier ein wenig schlau macht, erweitert man seine Möglichkeiten ungemein.

@SDH.Prod: was Dir noch fehlt ist das Daten-Alignment (Hilfe mir fehlt jetzt der Fachausdruck dafür), das ist die Art, wie Daten im Speicher ausgerichtet sind. In einem 64 Bit System sind Daten anders ausgerichtet als in einem 32 Bit System und außerdem ist das (glaub ich) auch eine Compiler-Einstellung.

Stichwort: Packed Records in Delphi zum Beispiel, hier kann man den Compiler zwingen, das normale Daten-Alignment hier nicht anzuwenden.

Ich lerne auch immer wieder mal was Neues, InstanceSize() kannte ich auch noch nicht.
Viele Grüße
Traude

Naja, ich will eigentlich nur wissen ob die Rechnung richtig ist (besonders ob die Aussage das String zusätzlichen dynamischen Speicher brauchen so richtig ist oder ob der Verbrauch nicht doch statisch auf 255 bzw 256 Byte ausgelegt ist).

Es mag sein das dies wirklich wenige kByte sind, allerdings sind 2 dinge entscheidend:
1. ich hatte ursprünglich einen Fehler beim "umbau" meines Quelltextes, wodurch die Kartengröße auf das Maximale oder so lief (also 65535 * 65535 * 100) und dabei kam ein OutOfMemory herangeflogen. Da die größe an sich nicht beschränkt ist (ausser jemand will wirklich mal 2D-Karten in der Größe von 65535 * 65535 * 100 machen O.o), wäre es sicherlich gut wenn man sich vorher errechnen kann ob das nicht doch dann gewaltig wird.
2. Das Programm ist Hauptbestandteil meiner Belegarbeit und ich muss ja mit irgendwelchen Wissen 10 Seiten voll kriegen.

"Was soll das bringen? Ein Pointer ist 4 ( oder 8 ) Byte groß, die Ersparnis wäre doch eher gering."
Ja aber diese Zeiger von den Feldern sind ja aufgrund der großen Anzahl der Felder auch sehr häufig vorhanden (siehe Beispielrechnung, ein Feld braucht durch die Zeiger das 4-Fache an Speicher und bei 99999999 Feldern macht das schon was aus).

Der Standard String ist ein 256Byte langer array of char, wobei der Pointer auf den String auf das 2. Char gesetzt wird, im ersten Char die länge geschrieben wird und somit noch 255 Byte über sind.
Alles innerhalb von 255 Zeichen pro string ist ganz und garnicht dynamisch sondern schon vorher alloziiert worden.
Neben den Klasseninstanz-Daten gibt es noch die RTTI Daten, welche zwar nur pro Klasse einmal global existieren aber schnell massiv viel speicher verbrauchen kann, im vergleich zur Klasseninstanz.
Das Problem hierbei sind Sprachfeatures wie overload, virtual, inherieted, properties und published.
Virtual sorgt dafür, das für jede Klasse der Funktionspointer hinzu kommt, sobald sie in einer abgeleiteten Klasse wieder auftaucht, die Properties und Methoden im Published bereich sind teil vom RTTI und RTTI-Daten sind sehr Groß, da neben einem String(Name), noch grober DatenTyp, genauer Datentyp, Addresse, Setter und Getter abgelegt werden. Da ist auch je nach dem einiges andere, was hinzukommt.
Wenn man also das OOP Prinzip sehr eisern durchzieht ist der Speicherverbrauch wesentlich höher, da man sehr viele Klassen(viel RTTI krams) und nur wenige Intanzen hat und somit der kosten/nutzen Faktor schlechter ist als wenn man alles in weniger Klassen zusammen zieht und somit mehr instanzen hat und die RTTI Daten dann im Verhältnis weniger Speicher aus macht.
Die Thematik ist leider auch immer mit Vorsicht zu geniessen, da zwischen den compilern und Sprachversionen unterschiede gibt, einiges wird raus optimiert anderes fällt weg kommt hinzu... .

In deinem Beispiel, wäre es z.B. sinnvoll eine Map zu haben, wo die Daten ein 1D Array aus records wäre.
Der 1D Array kostet dich sizeof(recordtyp)*felderanzahl aber ein array of array z.B. kostet dich (sizeof(recordtyp)+sizeof(pointer))*felderanzahl, wobei das noch recht ungenau ist, da ja ein array ja noch zusätzlich eine zählervariable beinhaltet.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

naja, mal ehrlich... So groß können die RTTI-Daten auch nicht sein. Mal ganz davon abgesehen, dass ein paar strings für den Feldnamen und getter / setter für properties auch relativ klein sind (1 byte / char strings, wo hat man sowas heutzutage noch ), das ganze wird ja wie du gesagt hast, nur einmal pro Klassendeklaration abgelegt. Und außerdem hat man normalerweise nichts im published-Bereich (es sei denn, man schreibt Komponenten oder will sich das Leben mit Skripten schwer machen *g*). Oder ist der public-Teil auch in der RTTI enthalten? Sollte imho nicht...

Gerade wenn man das mal mit Java vergleicht - da gibt's nämlich für jedes Feld RTTI. Ja, auch für private felder etc. Und da hat man für gewöhnlich noch wesentlich mehr Klassen als in Delphi.
Und guckt man sich den Speicherverbrauch von Java-Anwendungen mit einem Profiler an, so stellt man ganz schnell fest, dass über 90% des Speichers für String-Instanzen - genauer: arrays von chars draufgehen. Der Anteil der RTTI am Gesamtspeicherverbrauch sollte also imho ohne Gewissensbisse sehr vernachlässigbar sein. Konkrete Zahlen dazu wären freilich dennoch interessant.
Und noch eins: Bei Java sind grundsätzlich erstmal alle Methoden virtual. Soll jetzt keine Werbung für den hohen Speicherverbrauch von Java sein (hö?), sondern im Gegenteil zeigen, dass Delphi da wesentlich speicherschonender ist.

Btw ist mir nicht so ganz ersichtlich, warum das Deklaration / Instanzen - Verhältnis bei mehr OOP zwingend schlechter (= größer) sein sollte als bei weniger OOP, aber das ist auch ein wenig OT...

Letztendlich hat man, wenn man mal ein, zwei Texturen geladen hat, allen durch Klassen(-Deklarationen) "extra" verbrauchten Speicher in einen nicht mehr wahrnehmbaren Bruchteil verbannt Die Speicherproblematik findet folglich glücklicherweiße mehr bei extremen Randfällen Beachtung.

Edit: Ein paar Hausnummern hätt ich noch: Nehmen wir mal an, man hat bei recht stark OOP-lastigem Code 2000 Klassendeklarationen, im Schnitt 5 published properties (was imho realitätsfern ist, da wie gesagt bei published normalerweise nix steht)... Nehmen wir an, wir brauchen 2 Bytes für die Datentyp-Definition in der RTTI, einen im Schnitt 8 byte langen string für den feldnamen, insg. 8 Byte für Pointer zu setter und getter... Dann kommen wir auf 2000 * 5 * (8 + 8 + 2) => 180.000 Byte und ergo 180 kByte für die properties. Dazu noch 2000 * 20 Byte für den Klassennamen (bei langen, aussagekräftigen Klassennamen) => 40 kByte. Und spendieren wir meinetwegen noch 10 virtuelle Methoden pro Klasse: 2000 * 10 * 4 => 80 kByte.

Summa Summarum: 300 kByte für die gesamte RTTI im Worst-Case. Also entweder wird da noch wesentlich mehr reingespeichert (wüsste aber nicht spontan nicht was), oder ich hab mich verrechnet oder das ist viel heiße Luft um nix
Und ich hab hier aus Gründen der Faulheit mit 1000 statt 1024 gerechnet :p

Edit 2: Ha, ich hab was vergessen *g* Die Adressen :p Aber die paar Bytes reißen es dann glaube ich auch nicht mehr raus ^^

Grüße,
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

@Tak2004

Standard string ?
Du meinst wohl eher ShortString ?!

@Topic

Ein String wird in Delphi als Pointer behandlet -> PointerSize = 4 Bytes; dies sieht man ganz schön an dem folgenden Beispiel:



-> eax wird dereferenziert ! also = Pointer

Sobald du eine String Variable zu deiner Klasse hinzufügst, erhöht sich die Größe deiner Instanz (InstanceSize) um genaue 4 Bytes - EGAL wie lang nun der eigentliche String ist.

Falls du jedoch typisierte Strings - sowie Shortstring ( intern = Array[Byte] of Char ) verwendest, dann siehst du auch, wie groß nun wirklich die Klasse ist!

MfG

_________________
...GOD is wearing black...

@Emre: Klar sind das nur Pointer, aber die Daten, zu denen sie hinzeigen, brauchen ja Speicher *g*
Für dynamische Strings rechnet man ergo Pointergrößer + Größe der Längenangabe des Strings + Zeichenzahl des Strings. Pointer und Längenangabe sind imho aber vernachlässigbar, entscheidend sind also immernoch die Zeichen selbst. Und das sind bei normalen strings 1 Byte pro Zeichen.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Das ist ja logisch

Ich wollte es ja nur hervorheben, da der Threadstarter nicht verstanden hat, warum sich die Größe der Instanz (bzw Klasse) nicht geändert hat

MfG

_________________
...GOD is wearing black...

Ich würde nicht sagen, dass die Stringinfos + Pointer vernachläsigbar sind. Wenn du normale (long oder Huge) Strings hast, dann belegt der Pointer 4 Bytes und die Zusatzinfos 12 Bytes. Neben einer Längenangabe gibt es noch eine Speichergröße und einen Referenzzähler. In Delphi 2009 kommt auch noch eine Angabe der verwendeten Codepage dazu (infos dann größer als 12 Bytes). Bei String, mit einer Länge kleiner als 16, überwiegen also die Verwaltungsdaten bereits der tatsächlichen Datengröße. Wenn man eine passende Anzahl an Strings sind, dann kommt da schon einiges zusammen. Wenn das aber nur ein paar sind, dann ist das aber mal so was von egal.

Zum Thema Größe berechnen. Es ist nahezu unmöglich genau zu bestimmen wie viel Speicher eine Anwendung belegt. Denn es gibt Faktoren die du nicht berechnen kannst. Die Fragmentierung des Speichers. Delphi alloziiert größere Speicherblöcke vom Betriebssytem. Wenn du jetzt dynamischen Speicher erstellst, dann werden der in diese Blöcke verteilt. Löscht du Instanzen oder dynamischen Speicher (Strings), dann werden diese Bereiche innerhalb der Blöcke als frei markiert. Dadurch entstehen genau wie auf einer Festplatte auch Lücken. Diese Lücken werden zwar mit neuen Instanzen gefüllt. Aber es können trotzdem kleine Löcher entstehen. Oder aber falls alle neueren Instanzen größer sind als der freie Platz, dann bleiben solche Lücken länger frei. Beim Vergrößern von Strings kann es auch gut passieren, dass Lücken entstehen. Nämlich dann wenn hinter dem String bereits etwas liegt. Dann muss er komplett verschoben werden und ein größeres Loch entsteht. Nicht zu vergessen, dass der Speichermanager auch Informationen über den verwendeten und freien Speicher halten muss. Woher soll er sonst wissen was frei ist und was nicht. Obendrein kann es auch gut mal passieren, dass Delphi von einer auf die andere Version etwas an den internen Strukturen verändert. Und dann braucht eine einzelne Klasseninstanz urplötlich 2-4 Bytes mehr. Abgesehen davon bekommen Speichermanager vor Turbo Delphi einen Schock, wenn man viele Instanzen (schätzungsweise 100.000+ (weiß nicht mehr 100%tig)) freigeben will. Das Freigeben dauert dann deutlich länger als das Erstellen.

Generell find ich es aber auf jeden Fall sehr wichtig zu wissen und sich auch Gedanken darüber zu machen wie viel Speicher man verwendet. Für deine Belegarbeit aufzuführen wie viel Speicher verbraucht wird dürfte zu mindest Zeigen, dass du nicht blindlings arbeitest sondern dir ein paar Gedanken machst. Allerdings selbst die Teile aufzuzählen von denen du maximal 4 Instanzen hast finde ich etwas zu viel. Da würde ich überwiegend nur die großen Brocken aufzählen. Zum Beispiel der Texturspeicher und der Speicher für die Karte. Bei der Karte also detailiert aufführen was ein Feld belegt und was das als Gesammtes sein wird. Immer mit dem Hinweis, dass eben nicht alles aufgelistet werden kann und einige Teilwe wegen Nichtigkeit weggelassen werden. Zu viele Werte dürften da eher nur verwirrend wirken. Und ob die Effekte jetzt nun 200 oder 216 Bytes belegen interessiert im Vergleich zu 20 MB Texturen auch nicht wirklich.

Zu deinem Problem mit den großen Karten. 65535*65535*100 = 429.483.622.500 Bytes = 409 MB. Das sollte normal schon in den Speicher passen. ABER nicht am Stück. Der Speicher im RAM fragmentiert auch. Wenn du Pech hast sind von den über 2 GB die im RAM noch frei sind aber jeweils nur maximal 200 MB am Stück frei. Wenn du jetzt aber 400 MB am Stück haben willst, dann wird dir Windows eines Husten. Wenn du aber jeweils 1-16 MB Blöcke anforderst, dann wirst du wohl auch die kompletten 409 MB bekommen. Und noch mehr. Allerdings kommt es immer auf den Anwendungsfall an, welche Struktur man verwenden kann und welche nicht. Wenn du solchen großen Felder benötigst, dann brauchst du eine andere Struktur. Wenn alles über 2000x2000 sowieso keinen Sinn mehr machen würde, dann kann man das entweder begrenzen oder mit einem Hinweis versehen. Aber das kann ich natürlich nicht abschätzen.

PS: Speicherangaben in BITs sind wirklich etwas übertrieben. Höchstes der Verbrauch des Programmierers auf 1000 Quellcodezeilen in BITs wären okay. (Bitte)