liste memory leak

Kann man den std::listen und vektoren denn irgendwie mitteilen, dass sie nie debugged werden sollen? Ich brauche die Debuginformationen der Listen nicht, jedoch die des restlichen Programms. Wäre nämlich praktisch, wenn die Listen im Debugmodus auch so schnell wären.

drakon

Du kannst das über die defines lösen:

#define _HAS_ITERATOR_DEBUGGING 0

Und dann die Header inkludieren. Bin jetzt nicht sicher, ob noch andere defines nötig sind.

unskilled

daniel1984 schrieb:

Kann man den std::listen und vektoren denn irgendwie mitteilen, dass sie nie debugged werden sollen? Ich brauche die Debuginformationen der Listen nicht, jedoch die des restlichen Programms. Wäre nämlich praktisch, wenn die Listen im Debugmodus auch so schnell wären.

Ich kenn keine Möglichkeit - sicher, dass es an den listen liegt?
ich denke, es gibt andere dinge, die viel mehr asserts ausführen, als ne liste... hört sich auch so an, als ob du immernoch die falsche datenstruktur verwendest wofür ist die Liste denn nun genau da? Welche operationen werden darauf ausgeführt? Wie oft?

btw: was is das problem, wenn du im debugmode halt nur 40FPS hast?

bb

unskilled

drakon schrieb:

Du kannst das über die defines lösen:
#define _HAS_ITERATOR_DEBUGGING 0
Und dann die Header inkludieren. Bin jetzt nicht sicher, ob noch andere defines nötig sind.

das sollte es jz nicht so extrem langsam machen!? aber wenn wir schon mal dabei sind:
#define _SECURE_SCL 0
wird auch noch paar prozent(promille^^) ausmachen

allerdings würd ichs so machen:

#define _SECURE_SCL 0
#undef _DEBUG

#define NDEBUG //aber nur, falls du alle asserts deaktivieren möchtest...

allerdings müsstest du dir sicher sein, dass das vor dem ersten vector/list/...-include kommt...

bb

drakon

Kommt auf die Anforderung an, was alles ausgeschaltet werden kann. Aber mir ist das ganze auch ein wenig Suspekt. - Ist ja egal, wenn es im Debug Mode langsamer ist..
Allerdings kenne ich das, dass sich mit dem Overhead, der sich ergibt kaum noch etwas Debuggen lässt, wenn es so lange dauert..

Danke euch!

Nützlich im Fall, wenn das das Spiel im Debugmodus unspielbar werden sollte.

@unskilled:

Ich wollte mir gerade dein Diagramm genauer ansehen. Wahrscheinlich habe ich wirklich die Falsche Struktur.

Um es kurz zusammenzufassen: Meine Spielobjekte werden in Vektoren gespeichert. Die Anzahl der Objekte ändert sich selten. Die Vektoren werden aber dauernd durchlaufen.

Die Liste, um die es ging, führt jedes Objekt mit sich und speichert soll darin speichern, welche Objekte in der Nähe liegen. Ich arbeite an sowas wie Schwarmverhalten. Da nicht immer gleich viele Objekte in direkter Nähe sind, kann die Listengröße variabel sein. Die Liste sollte außerdem nach der Distanz zu den Objekte sortiert werden Welche Datenstruktur würde am besten passen?

Die deque scheint es zu sein, laut dem Diagramm!

Ist mir noch völlig unbekannt und wird jetzt genauer unter die Lupe genommen

unskilled

Und Distanz ist ein float oder ein int? Gibt es eine maximal-Zahl an Objekten in der Nähe? kannst du die zumindest abschätzen? wie groß sind die objekte, die du speicherst? also was sagt sizeof(instanz_eines_objektes)?

Distanz ist ganzzahlig: würde ich vll multi_map nehmen (wenn du alle objekte durchgehst, ist das hier allerdings schon wieder ne all zu dolle^^)
vll auch ne priority_queue, allerdings hab ich die noch nie verwendet und weiß demzufolge auch relativ wenig über sie und wie man sie "missbrauchen" kann
wenn das beides nich besser ist, dann würd ich deque und list mal vergleichen...

bb

camper

Ist das also eine Liste aus Zeigern? Höchstwahrscheinlich ist hier vector am effizientesten - Einfügen außer am Ende ist zwar etwas teurer - aber wenn diese vectoren nur eine vielleicht zweistellige ANzahl an Elementen haben, ist das immer noch kaum wesentlich teurer als etwa list, bei dem wir für jedes Element eine gegebenenfalls teuere Allokation (kann man u.a. durch optimierte Allokator verbessern) durchführen müssen. Dafür ist dann alles andere weitaus einfacher zu optimieren, zudem ist der Speicherverbrauch deutlich geringer.

Also um genauer zu sein speichere ich nur Zeiger auf die Objekte. Die belegen nicht viel Speicher oder?

Jede Objektgruppe befindet sich in einem Vektor. Diese sind verknüpft und werden beim Rendern rekursiv durchlaufen. Es ist sowas wie ein Baum von Vektoren.

Für die Distanzen würden vermutlich Integer Werte reichen. Die Anzahl der nahen Objekte sollte begrenzt sein, um den Rechenaufwand in Grenzen zu halten. Ich werde mir gleich mal die verschiedenen Datentypen ansehen.

Ich habe noch die Priority Queue eingebaut. Das erstaunliche ist, dass es damit kaum schneller ist (mit 5 nahen Objekten), als wenn ich ohne Priority Queue alle Objekte durchlaufe Vielleicht lohnt es sich erst bei mehr Objekten (ich habe nur 50). Ich werde mich gleich mal an den anderen Datentypen versuchen. Mit Priority Queue sinkt es im Debugmodus sogar auf 5 FPS (240 FPS im Release Modus).

Nexus

Bei so wenigen Objekten machen sich Unterschiede der Container kaum bemerkbar, meist zeigen sich diese erst ab mehreren Tausend bis Millionen Elemente (je nach Elementgrösse halt).