Speicherverwaltung ein fall für die Engine?

[IlikeMyLife]

Gibt mal wieder eine Frage für "Was ist wenn" von mir.

Ich habe ( obwohl einige C++ ) Kenntnisse besitze, nochmal von ganz von vorne begonnen um altes auffrischen zu können und um lücken zu schließen.
derzeit bin ich beim lernen bei dem thema, "Klassen", "Konstruktor und Destruktor", "Speicherverwaltung auf dem Heap".

Im Zuge dieser Kapitel habe ich mir folgende Frage gestellt:
Gehen wir von dem Beispiel aus, das ein RTS ( Real-Time-Strategie ) programmiert werden soll und ich InGame Einheiten produzieren möchte.
Ich gehe ja nun davon aus, dass in dem Moment, wenn ich eine Einheit baue, dass System mir eine Instanz vom Objekt "Einheit" auf dem Heap ablegt. Dieser wird nach einiger Zeit zerstört und wieder frei gegeben.

Wenn ich mir nun überlege, dass dieser Speicher ähnlich aufgebaut ist, wie die Festplatte, ist der Heap nach einiger Zeit im zustand, dass ich dermaßen fragmentiert wird, dass ich speicherverluste habe ( im sinne, dass ich speicheradressen zwischendurch habe, auf die keine Instanz mehr drauf passt ) und dieser Speicher mir dadurch verloren geht.

Ist es Sinnvoll das Thema der Speicherverwaltung in die Engine ( ich will eine eigene schreiben ) aufnehme oder sollte man dieses direkt im eigentlichen Code einbringen? Ist es Sinnvoll beziehungsweise möglich, den Heap beispielsweise während eines Ladebildschirms zu defragmentieren?

EDIT:
Korrektur meiner Aussage: Ich will eine vorhandene Engine nehmen und diese erweitern

[Lynxeye]

Rein theoretische, idealistische Aussage:
Speicherverwaltung gehört immer ins Betriebssystem und hat in Userspaceprozessen, außer dem allokieren und freigeben, nichts zu suchen. Von daher: nein, keine Aufgabe der Engine, dein Betriebssystem bzw. deine CRT sollte selbst in der Lage sein den Heap so sauber wie möglich zu halten.

Eher praktisch orientierte Antwort:
Wenn du noch in der 32 Bit Welt lebst hast du es etwas schwerer, denn da hast du nur 4GB Prozessadressraum, eine Verlust von virtuellen Adressen schlägt also wirklich hart durch. Wenn du in der 64 Bit Welt lebst, kannst du das Thema vergessen, dort hast du mehrere TB virtuellen Adressraum. Du kannst also ca. die tausendfache Menge an virtuellen Adressen durch Fragmentierung verlieren, bevor du keinen physischen (wirklich an RAM vorhandenen) Speicher mehr an deinen Prozess durchreichen kannst.

Hohe Fragmentierung kann allerdings unter Umständen zu Performanceproblemen führen, wenn die vom Betriebssystem zur Heapverwaltung verwendeten Algorithmen in ihrer Laufzeit von der Zahl der Fragmente abhängt.

Die Frage, welche du dir stellen solltest ist: kann ich es wirklich besser machen, als mein Betriebssystem? Speicherverwaltung ist kein Thema, was man mal schnell in ein paar Tagen abhakt. Wenn man wirklich etwas damit heraus holen möchte, muss man sich viele Gedanken über Objektcaches, Speicherlayouts, usw. machen und seine Engine darum herum bauen. Das ist nichts, was man mal schnell in ein bestehendes System nachrüstet. Wenn du nicht wirklich sehr viel Zeit in das Thema investieren willst, lass es, vertraue auf dein BS und hoffe, dass die Speicherverwaltung im BS sich schneller weiter entwickelt, als es für dich zum Problem wird.

[IlikeMyLife]

Das sind beruhigende worte :D

ja, ich bewege mit in der 64-Bit Welt. War mir bislang unbekannt, dass das Betriebssystem die Aufgabe übernimmt. Aber nun ja... Da hat sich ja ein ganzes Thema arbeit für mich erledigt wie es scheint.

[Krishty]

Lass das wirklich Problem des Betriebssystems sein.

Als 64-Bit-Prozess stehen dir unter Windows 8 TiB Adressraum zur Verfügung; das wäre genug, um jede Datei deines Systems zu mappen und trotzdem zig Speicherlecks bei tagelanger Laufzeit zu haben (vorausgesetzt, die Auslagerungsdatei ist groß genug ;) ). Diese 8 TiB laufen mit einem Low Fragmentation Heap, der bei Mikroallokationen (bis 16 KiB) Fragmentierungsfreiheit gewährleistet und bei Makroallokationen (ab ein paar GiB) roh allokiert. Falls das zu wenig sein sollte, kannst du via CreateHeap() einen Heap für die harten Fälle anlegen, bspw. für Allokationen, die sich jeden Frame wiederholen. Und falls du das dann noch mit eigener Speicherverwaltung toppen kannst, Hut ab.

Der beste Weg, sich keinen Kopf darüber machen zu müssen sind übrigens schlanke Datenstrukturen (einmal neben den Cache greifen kostet einen Core i7 400 Takte; via SIMD könntest du in der Zeit 10 Quadratwurzeln berechnen – überleg dir also, wann eine Datenstruktur von einem Vektor eine zusätzliche, normalisierte Kopie braucht) und RAII (weil sich damit dynamische Alloktionen zu einem Gros vermeiden lassen; von der Vereinfachung der Programmlogik ganz zu schweigen).

Ganz gefeit bist du aber mit einem x64-Prozess nicht – falls etwa deine Anwendung ohne /LARGEADDRESSAWARE-Flag kompiliert sein sollte (bspw. durch Rumpfriemelei an den Projekteinstellungen oder durch ungünstiges Kopieren der x86-Projekteinstellungen), kommst du trotz allem nicht über 2 GiB hinaus und stehst genau so mit heruntergelassenen Hosen da wie unter x86. Nicht zuletzt auch, wenn der Anwender einfach zu wenig freien RAM im System hat (wobei dann ja streng genommen Fragmentierung immernoch kein Problem ist).

Gruß, Ky

[dot]

/LARGEADDRESSAWARE ist damit 32bit Prozesse mehr als 2GB haben können. Für einen 64bit Prozess sollte das meines Wissens nach keinen Effekt haben. Aber ein 32bit Prozess der auf einem 64bit OS läuft kann damit afaik die vollen 4GB ausschöpfen.

Edit: Ok für 64bit ist /LARGEADDRESSAWARE per default ein. Wär interessant obs wirklich was machen würd, wenn es aus wäre.

[Krishty]

User-mode virtual address space for each 64-bit process

Limit in 64-bit Windows:
With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default):
x64: 8 TB
Intel IPF: 7 TB
2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared

Abwärtskompatibilität ist alles!

[dot]

Ok, das war mir neu :)

[Krishty]

Damit all die netten Leute, die Zeiger-Tricks in ihren Programmen benutzen, in Benchmarks von x64-Leistung profitieren können ohne sich anstrengen zu müssen ;)

[eXile]

Ganz gefeit bist du aber mit einem x64-Prozess nicht – falls etwa deine Anwendung ohne /LARGEADDRESSAWARE-Flag kompiliert sein sollte (bspw. durch Rumpfriemelei an den Projekteinstellungen oder durch ungünstiges Kopieren der x86-Projekteinstellungen)

Welche Optionen in den Standardprojekteinstellungen gibt es überhaupt deiner Meinung nach überhaupt noch, die sich im Normalfall noch lohnen? (Damit meine ich natürlich nicht Include- oder Librarypfade, etc.)

[dot]

Ich würde z.B. mal sagen SSE2 Instruction Set aktiviern (wenn du auf Windows > XP abzielst gibts wohl praktisch keinen Rechner mehr der kein SSE2 hat), evtl. Floating Point Model auf fast stellen.

[Krishty]

SSE2 ist doch ab x64 sowieso aktiv? Und x86 optimieren ist eh für die Katz’ …
/fp:fast hat in meinen Stichproben nie auch nur einen Befehl geändert. Abgesehen davon kann ich es nicht gebrauchen, weil ich öfters mal mit NaN und Unendlichkeiten hantiere.

/Ox mache ich immer an, obwohl MS davon zugunsten für /O2 abrät. KA, was der Unterschied ist. Meine Programme waren auch nie zeitintensiv genug, um da was spüren zu können.
/GS mache ich in Release-Builds immer aus, weil ich dieses Sicherheitsnetz dank leistungsfähiger Templates und ständigem Testen der Debug-Builds wirklich nicht gebrauchen kann.

Anonsten fällt mir auch nichts ein. Die Projekteinstellungen für Release sind wirklich von Werk aus knapp an der Perfektion; von Entwicklungshilfen wie Warnstufe 4, Mehrkernkompilierung und Debug-Informationen beim Linken mal abgesehen.

Um beim Thema zu bleiben: Dynamische Allokationen sind was, was kein Optimizer der Welt anfasst, abgesehen von [Füllraum für drei beliebige, von eXile rausgekramte Ausnahme-Veröffentlichungen] … die zu vermeiden ist also eine Optimierung, die sich für den Programmierer tatsächlich noch lohnen könnte.

[dot]

SSE2 ist doch ab x64 sowieso aktiv? Und x86 optimieren ist eh für die Katz’ …

Ich dachte es geht ihm um x86. Mit /arch:SSE verwendet der Compiler nicht nur SSE Instructions, sondern z.B. auch cmov.

/fp:fast hat in meinen Stichproben nie auch nur einen Befehl geändert. Abgesehen davon kann ich es nicht gebrauchen, weil ich öfters mal mit NaN und Unendlichkeiten hantiere.

Hängt natürlich vom Projekt ab, ob es was bringt. Hattest du da denn schonmal Probleme mit NaN und Inf? Wenn ja würd mich interessieren, wie die zustandegekommen sind.

/GS mache ich in Release-Builds immer aus, weil ich dieses Sicherheitsnetz dank leistungsfähiger Templates und ständigem Testen der Debug-Builds wirklich nicht gebrauchen kann.

Jap, das mach ich auch, seh ich genau so.

[Krishty]

Mit /arch:SSE verwendet der Compiler nicht nur SSE Instructions, sondern z.B. auch cmov.

Das wusste wiederum ich nicht. Hübsch.

/fp:fast hat in meinen Stichproben nie auch nur einen Befehl geändert. Abgesehen davon kann ich es nicht gebrauchen, weil ich öfters mal mit NaN und Unendlichkeiten hantiere.

Hängt natürlich vom Projekt ab, ob es was bringt. Hattest du da denn schonmal Probleme mit NaN und Inf? Wenn ja würd mich interessieren, wie die zustandegekommen sind.

Nein, Probleme hatte ich noch keine – wie gesagt, die Stichproben sahen alle gleich aus. Wenn ich mir aber die Liste der Optimierungen, die dann aktiv werden, ansehe, wird mir echt mulmig weil garantiert irgendwo noch ein if(x != x) in meinem Text steckt (zumal ich ja damals noch nicht alle entsprechenden Tricks umgesetzt hatte) :)

[dot]

Wenn ich mir aber die Liste der Optimierungen, die dann aktiv werden, ansehe, wird mir echt mulmig weil garantiert irgendwo noch ein if(x != x) in meinem Text steckt

OK, mit solchem Code würd ich mich wohl auch nur eher ungern in /fp:fast Territorium begeben ;)

[Krishty]

Noch ein Nachtrag zu x86 für die Katz’: Es ist tatsächlich so, dass Microsofts x64-Optimizer wesentlich leistungsfähiger ist; insbesondere durch viel aggressiveres Inlining und die hohe Registerzahl und nicht wegen der paar Anweisungen, die SSE einführt. Ich habe zeitkritische Stellen durch VC unter x64 auf ein Viertel ihrer x86-Laufzeit schrumpfen sehen – die waren zugegebenermaßen schlecht entworfen und implementiert, aber solcher Quelltext regiert nunmal die Welt. Die quasi-kostenlose Ausnahmebehandlung und das Speicherfragmentierungsthema tun ihr Übriges. Ich würde wirklich nichts mehr für x86 entwickeln, so lange es nicht dringend nötig ist.

[IlikeMyLife]

Dann hat sich dieses Thema letzt endlich erledigt :-)

[CrystalCoder]

Hallo erstmal,

bevor man sich Gedanken darüber macht, ob es Sinn macht einen Speichermanager zu schreiben, sollte man sich erstmal fragen, ob man es besser hinbekommt, als das Betriebssystem. Effiziente Speicherdefragmentierung ist nicht gerade einfach mal so programmiert und wenn man zur Laufzeit gerade Zeiger verschieben muss braucht man auch ein Konstrukt, das dafür sorgt, dass alle aktiven Zeiger nach wie vor gültig sind.

Sinn würde es ganz sicher machen, wenn man ein Konzept hat das perfekt auf das Einsatzgebiet abgestimmt ist, da das Betriebssystem alleine dadurch schon Fragmentierung erzeigt, wenn man einen Haufen Speicher in kleinen Häppchen allokiert, da das Betriebssystem den Arbeitsspeicher in Sektoren unterteilt und man nicht weniger Speicher allokieren kann, als diese Mindestgröße vorgibt. Man würde also ungewollt Speicher verschwenden.
Auch könnte man abschätzen wie viel Arbeitsspeicher genutzt wird (wenn man eine Höchstanforderung einhalten muss).

In allem kann man in den meisten Fällen davon abraten.
Wenn man es aber einfach mal gemacht haben will, ist es schon ne gute Übung wenn man sich daran versucht, sich einen kleinen Speichermanager zu schreiben. Man kann recht viel dabei lernen (Pointer verinnerlichen und sich ein Bild davon machen wie sowas gemacht wird, um seine Programme effizienter zu machen - mehrere kleine Allokationen zu größeren zusammenfassen, wie Krishty schon sagte - und ähnliche Optimierungen).


Zu der Sache mit dem virtuellen Arbeitsspeicher:
Man sollte nicht einfach davon ausgehen, immer 4GB und mehr an Arbeitsspeicher zur Verfügung zu haben.
Wenn man da nicht aufpasst, kann das ganz schnell zu einem riesigen Problem werden. (Mal von Hintergrundprogrammen abgesehen)
Angenommen man entwickelt auf einem PC mit 8GB Arbeitsspeicher, den man "gut" ausgenutzt hat, und ist dann fertig mit seinem Spiel. Man gibt das Spiel weiter und es wird von jemandem auf einem Laptop getestet, welcher 2GB Arbeitsspeicher hat. Folge davon ist meistens eine enorm große Auslagerungsdatei (welche evtl. durch das Betriebssystem auf z.B. 3GB beschränkt ist), wodurch das Spiel entweder einfach mit einer Fehlermeldung abstürzt oder bei 10FPS kriecht, trotz ansonsten geringen Systemanforderungen.
Die Aufgabe das ganze auszubügeln kann u.U. nochmal so lange dauern wie man für das Projekt investiert hat, da man sehr grundlegend in sein Design eingreifen muss (und auch die ganze Debugphase vorn anfängt).
Besser dagegen wäre: Ein Ressourcenmanager (- der problemlos mit einem evtl. exisiterenden Speichermanager zusammenarbeiten könnte), welcher sich am besten an die gegebene Arbeitsspeichergröße anpasst und angeforderte Ressourcen in einem Durchlauf selbst nachlädt und (wenn auch nur halbwegs) intelligent cacht.
Das ganze ist natürlich nur sinnvoll wenn man wirklich viele Ressourcen zu verwalten hat - Spiele mit sehr kleinen Szenen können den Punkt vernachlässigen, aber es ist dennoch ganz gut, das im Hinterkopf zu behalten.


EDIT: Irgendwie lustig, was passieren kann wenn man "ne Weile" anderweitig beschäftigt ist :D

Beiträge: 1
Registriert: 03.03.2002, 17:51

MfG,
CC

[Psycho]

Solid first post.

[kaiserludi]

LOL 2002er *facepalm*

[Krishty]

… dem ich aber nicht komplett zustimmen kann:

da das Betriebssystem alleine dadurch schon Fragmentierung erzeigt, wenn man einen Haufen Speicher in kleinen Häppchen allokiert, da das Betriebssystem den Arbeitsspeicher in Sektoren unterteilt und man nicht weniger Speicher allokieren kann, als diese Mindestgröße vorgibt. Man würde also ungewollt Speicher verschwenden.

Die interne Fragmentierung ist höchstwahrscheinlich kaum der Rede wert, da die Sektorgröße gemessen an der Speichermenge winzig ist – für Mikroallokationen beginnen die Sektoren mit einer Größe von acht Bytes; was ich über mittelgroße und Makroallokationen gelesen habe, lässt auf ähnliche Verhältnisse schließen. Diese Benchmark geht von 6 % Verschnitt nach 25 mio Allokationen aus – bis man so viel Unkosten hat, muss man den Speicherbedarf eh auf die Spitze treiben.

Die externe Fragmentierung ist happiger, und stand iirc auch schon vereinzelt bei Browsern zur Diskussion – allerdings nur unter x86. Um die 8 TiB Adressraum eines x64-Prozesses so arg zu fragmentieren, dass man keinen zusammenhängenden 2-GiB-Block mehr finden kann, braucht es 4000 ungünstig verteilte Allokationen. Die werden entsprechend ihrer Größe in lokalen Blöcken gebündelt und verpesten den Adressraum dadurch nur bedingt; man kann das also z.B. nicht durch hundertmilliardenfaches Allokieren und Freigeben von 8-Byte-Blöcken erreichen. Ich würde sogar sagen, dass so eine Fragmentierung zum heutigen Zeitpunkt (Vista/7 mit 16 GiB RAM) quasi unmöglich erreichbar ist.

Es ist nicht nur in den meisten, sondern in allen Fällen davon abzuraten ist, nur aus Angst vor Speicherfragmentierung einen eigenen Allokator zu schreiben. Es gibt viele gute Gründe für Pooling, aber die Fragmentierung ist keiner.

Man sollte nicht einfach davon ausgehen, immer 4GB und mehr an Arbeitsspeicher zur Verfügung zu haben.

Nö. Aber von 8 TiB virtuellem Adressraum schon.

[CrystalCoder]

Gut, die Quelle wo ich das her hab ist schon etwas älter. Ich beschäftige mich an sich nicht sehr viel derartigen Sachen. Fakt ist jedoch, dass es diese Fragmntierung gibt. Ist mmn nützlich zu wissen.

Es ist nicht nur in den meisten, sondern in allen Fällen davon abzuraten ist, nur aus Angst vor Speicherfragmentierung einen eigenen Allokator zu schreiben

Das ist natürlich klar. Selbst wenn man einen eigenen Allokator schreibt, kommt man nicht drumherum mehr Speicher zu nutzen, als reserviert wird alleine schon aus Debuggründen, z.B. um Falschzugriffe erkennen zu können.

Nö. Aber von 8 TiB virtuellem Adressraum schon.

Jo, da hab ich anscheinend net aufgepasst beim lesen.


EDIT:

LOL 2002er *facepalm*

auch so einer :P

[Chromanoid]

Ach ihr habt doch nur Glück, dass euer Registrierungsdatum rübergerettet wurde :D ich war schon im Forum registriert als zfx noch bei der TU Braunschweig/ezboard gehostet wurde :ugeek: :D .

[kaiserludi]

Selbst wenn man einen eigenen Allokator schreibt, kommt man nicht drumherum mehr Speicher zu nutzen, als reserviert wird alleine schon aus Debuggründen, z.B. um Falschzugriffe erkennen zu können.

Dafür gibts doch Debug- und Release-Configs ;)

Ach ihr habt doch nur Glück, dass euer Registrierungsdatum rübergerettet wurde :D ich war schon im Forum registriert als zfx noch bei der TU Braunschweig/ezboard gehostet wurde :ugeek: :D .

Kann mich noch an die Zeit erinnern, als die Seite noch stefanzerbst.de hieß und es noch richtig familiär zuging mit 2-stelliger Zahl angemeldeter Nutzer :ugeek:

[Krishty]

Kann mich noch an die Zeit erinnern, als die Seite noch stefanzerbst.de hieß und es noch richtig familiär zuging mit 2-stelliger Zahl angemeldeter Nutzer :ugeek:

[clewgshice]Ist doch heute immernoch so; nur registriert sind ein paar mehr ;)[/clewgshice]

[CrystalCoder]

Dafür gibts doch Debug- und Release-Configs ;)

Stimmt, daran hab ich jetzt garnicht gedacht.

Kann mich noch an die Zeit erinnern, als die Seite noch stefanzerbst.de hieß und es noch richtig familiär zuging mit 2-stelliger Zahl angemeldeter Nutzer

Ich find auch das hatte was damals. Mir hat aber die Farbe der Seite von damals etwas besser gefallen (nicht, dass ich was gegen das aktuelle Design habe, das ist schon ok, nur ist es mir persönlich bisi zu viel Blau).
Das war zu der Zeit als Band I gerade erst rauskam: http://web.archive.org/web/200105290115 ... zerbst.de/

Ach ihr habt doch nur Glück, dass euer Registrierungsdatum rübergerettet wurde :D ich war schon im Forum registriert als zfx noch bei der TU Braunschweig/ezboard gehostet wurde :ugeek: :D .

Wenn ich mich recht erinnere gabs damals mal nen Wechsel des Boards (oder es gab ein Problem mit dem aktuellen oder sowas), das hatte jedenfalls zur Folge, dass sich viele neu anmelden mussten, also stimmt das Datum auch nicht so ganz.

[Chromanoid]

Du kannst auch dein Theme umstellen :). Zur Auswahl stehen prosilver, prosilver-se (das was die Developianer voreingestellt bekommen haben), ZFX Nostalgia (Das Design, was http://old.zfx.info nachempfindet) und ZFX Pigeon Blue (ein versuchter neuer Style von mir, dessen größter Fan wohl ich selbst bin :D [der hat das geheime feature neue Beiträge auf der Frontpage leicht rosa zu unterlegen! :o :D ])

sooorry für das ot btw ^^

[joeydee]

Noch ein Nachtrag zum Thema: Am besten, man gibt von vornherein möglichst wenig Anlass zum "Aufräumen", z.B. indem man Pools für bestimmte Objekte schafft und den Objekten eine Methode zum Zurücksetzen implementiert (bzw. der Factory, die sie erstellt, oder der Pool-Klasse). Interessant überall, wo viele Objekte schnell gebraucht und ständig zerstört werden, bekannt auch von Partikelsystemen. Obs dann letztendlich wirklich was bringt oder die Poolverwaltung den Zeitgewinn frisst muss man natürlich testen...

[CrystalCoder]

Wenn man sich übrigens so einen Ressourcenmanager programmiert, ist es normalerweise eine gute Idee für jede Ressource mitzuspeichern wie viel Speicher diese belegt. Damit kann man das ganze dann noch etwas besser verfolgen und die Ressourcen besser organisieren. Damit erkennt man schnell wenn welche angefordert werden, ob man (wenn diese vorher erst geladen werden müssen) vorher seltener gebrauchte Ressourcen freigeben sollte. Das impliziert dann aber auch dass man sich Gedanken machen sollte in welcher Reihenfolge man was aus dem Ressourcenmanager anfordert (häufig gebrauchte Ressourcen gruppieren und sowas).

Du kannst auch dein Theme umstellen

Ahh schon viel besser, danke für den Tipp. Die Einstellung ist gut versteckt, hab etwas gebraucht um den "Persönlicher Bereich" Link zu erkennen, auch wenn ich ihn eigentlich schon gesehn haben müsste.
Dein Design ist schon ganz gut, ich bin nur kein Fan von dunklen und zu grellen Hintergrundfarben, ich finde das Herz passt farblich nicht besonders gut zu dem Rest des Logos und dem Titel. (Rosa auf der Hauptseite sieht eigentlich ganz nett aus, hebt sich aber stark von dem Rest ab. Ich nehme mal an das ist gerade das Feature an dem Style ^^. Da würd ich aber den Rest etwas anpassen, weil das ganze drumherum wirkt eher düster finde ich.)
prosilver ist recht klassisch gehalten und gefällt mir gut, ich hab jetzt mal prosilver special eingestellt :)

[NytroX]

Hmm, entweder ich habe es übersehen, oder es hat noch niemand den Low-Fragmentation-Heap erwähnt.
Ab Win Vista (ich gehe mal von x64 aus) ist der default-mäßig eingeschaltet und sorgt dafür, dass der Heap nicht zu arg fragmentiert, indem er allocs/deallocs < 16 KB optimiert.
D.h. wenn man nicht gerade riesige Mengen an Speicher allokiert (16 KB ist verdammt viel für "einfache" Objekte!) ist es eigentlich fast unmöglich,
dass die Fragmentierung den Heap dermaßen zerschiesst, dass keine Allokationen mehr möglich sind.

Wie schon erwähnt kann man für Objekte, die man dauernd wieder braucht, einen Pool erstellen (z.B. für Partikel-Effekte).
Das kann sich durchaus lohnen, aber hauptsächlich aus dem Grund, dass das OS/der Kernel nicht ständig für die allocs/deallocs aufgerufen werden muss.

Mal abgesehen davon ist das ja ne Engine, und kein super wichtiger Server. Bei Servern kann es aufgrund der Programmlaufzeit (z.T. mehrere Jahre) zu sowas kommen.
Schlimmstenfalls stürzt das Game halt einmal im Jahr ab :roll:

Von daher würde ich hier raten:
- Benutze Pools, wo es Sinn macht
- Kümmer dich erst um die Fragmentierung, wenn es ein echtes Problem wird, denn das wird vermutlich nie der Fall sein :D
- Achte eher auf memory leaks und solche Dinge ;)

[BeRsErKeR]

Man sollte nicht einfach davon ausgehen, immer 4GB und mehr an Arbeitsspeicher zur Verfügung zu haben.

Nö. Aber von 8 TiB virtuellem Adressraum schon.

Das kann aber auch mal in die Hose gehen, wenn du nur noch <= 4GB auf der Festplatte frei hast. Sowas soll vorkommen. Irgendwo ist immer mal die Grenze. Und 64Bit hat auch nicht jeder (mich eingeschlossen).