Allokationen Vermeiden

[foofel]

Hey,

es heißt ja immer man soll wenn möglich alle allokationen während des spiels vermeiden und alles vorher anlegen. Bei vielen sachen klappt das auch, aber es gibt dann doch einige sachen wo das den aufwand um einiges erhöhren würde. Z.B. für geschosse, ich könnte jetzt eine bestimmte anzahl vorher anlegen, und nur neue anlegen wenn ich über die anzahl der vorher erzeugten objekte komm etc. aber ist das den aufwand wirklich wert? Einige sachen wie gegner spawnen ja auch recht unregelmäßig und dann dafür nen pool anlegen... Wir handhabt ihr das und habt ihr da schon performance probleme bekommen? Bisher läuft das nämlich mit dem direkt erzeugen ziemlich super, aber man hört das halt immer wieder :)

[Schrompf]

Programmiersprache?

In C++: Allokationen kosten etwas Rechenzeit, vielleicht so im Bereich von ein paar Hundert Nanosekunden auf aktuellen Desktoprechnern. Deallokationen kosten u.U. das Vielfache, aber immernoch im Bereich <1µs. Das ist kein Problem, wenn man pro Frame ein paar Hundert Objekte anlegt, aber im Renderer mit potentiell vielen tausend Objekten pro Frame würde ich evtl. Umwege suchen.

In Java/C#: Allokationen kosten quasi nix, aber wenn Du fröhlich losallokierst, kommt irgendwann der Garbage Collector und Dein Spiel steht für ~5s. Es gibt Leute, die damit Spiele auf Steam veröffentlichen, also scheint es den normalen Spieler wenig zu kümmern, aber *mich* nervt sowas. Und der einzige Weg drumrum ist halt, Allokationen zu vermeiden. Das macht man üblicherweise mit Objekt Pools.

[TGGC]

Pack deine Geschosse einfach in einen std::vector, der regelt den Rest. Wenn du willst, kannst du spaeter als Optimierung noch ein reserve aufrufen.

[Chromanoid]

In Java/C#: Allokationen kosten quasi nix, aber wenn Du fröhlich losallokierst, kommt irgendwann der Garbage Collector und Dein Spiel steht für ~5s. Es gibt Leute, die damit Spiele auf Steam veröffentlichen, also scheint es den normalen Spieler wenig zu kümmern, aber *mich* nervt sowas. Und der einzige Weg drumrum ist halt, Allokationen zu vermeiden. Das macht man üblicherweise mit Objekt Pools.

Wobei diese Empfehlung mit Vorsicht zu genießen ist. Je nach JVM und GC-Einstellungen ist es mittlerweile häufig auch besser auf Pools zu verzichten. Die Oracle-Hotspot-VM macht beispielsweise Escape-Analyse um festzustellen ob überhaupt auf dem Heap alloziert werden soll. Allerdings ist das alles alles andere als deterministisch vorhersehbar und wenn man mit diesen Sprachen programmiert, sollte man sich so gut wie möglich einfach damit abfinden, dass der GC mal aktiv wird und kurz das Spiel anhält. Ansonsten kämpft man ja doch nur gegen die Konzepte der Sprache. Eine interessante Antwort dazu im Rahmen der Android-Spieleentwicklung auf Stackoverflow: http://stackoverflow.com/questions/1709 ... e-collecto

[Krishty]

Pack deine Geschosse einfach in einen std::vector, der regelt den Rest. Wenn du willst, kannst du spaeter als Optimierung noch ein reserve aufrufen.

Genau, denn sowohl der Container als auch das Betriebssystem reservieren Überhang, damit Vergrößerungen möglichst selten zu tatsächlichen Reallokationen führen.

[foofel]

Danke für die antworten, ich werd dann erstmal alles so lassen wie es ist und bei bedarf umbauen, bisher läufts ja :D