(gelöst)[Assimp] eigene Allokatoren verwenden

[Krishty]

Hi,

wie bekommt man Assimp dazu, eigene Allokatoren zu verwenden? Gibt es dafür bestimmte #defines, Header, Properties, o.Ä.?

Die Leistung der Standard-Speicherverwaltung bei PLY-Import ist bei mir ein ziemlicher Flaschenhals …

Nachtrag: Offenbar arbeitet sherief an einem entsprechenden Branch … gibt es irgendwas Neues von seiner Seite, oder ein absehbarer Fertigstellungstermin?

[Schrompf]

Ich weiß von nix. Außer halt, dass die Millionen von Kleinst-Allokationen in den aiFaces in der Tat ein gewisses Problem darstellen. Unsere eigenen Experimente mit einem Einweg-Allokator haben bei der DinnerTableOderWieHießSieNoch-Collada-Testdatei eine halbe Sekunde gespart bei 3s Gesamtlaufzeit beim Laden, sowie quasi die gesamten 2,5s beim Zerstören der Szene.

[Krishty]

Ja; das Zerstören ist bei mir ein riesiges Problem – falls ein Debugger angehängt ist, warte ich auch in der Release-Version fast eineinhalb Minuten bis die Szene zerstört ist. Der Profiler sagt, dass für new und delete 6,2 und 93,5 % draufgehen und nur 0,3 % (!!!) für das tatsächliche Laden.

Persönlich benutze ich nur noch Region-based Memory Management; aber ich weiß nicht, wo ich das schnell einbauen kann (ohne quasi alles an der Bibliothek umkrempeln zu müssen). Normalerweise würde ich einfach einen Allocator übergeben, der alles freigibt wenn der Import abgeschlossen ist … aber wohin übergeben?

[kimmi]

Ich habe dafür den folgenden Issue aufgemacht: https://github.com/assimp/assimp/issues/233 . Danke für die Anregung, mich stört das Ganze auch schon seit Jahren. Aber wie das halt so ist mit der eigenen Bequemlichkeit und Zeit :).

Gruß Kimmi

[Krishty]

Sooo. out-of-the-box braucht Assimp 32-Bit Release für dragon_vrip_res2.ply samt Freigabe 31 Sekunden. Mit dieser Quelldatei in der DLL

Code: Alles auswählen

#include <Windows.h>
#pragma warning(disable : 4074) // blah blah yadda yadda
#pragma init_seg(compiler)

struct Garbage {
	HANDLE heap;

	Garbage()
		: heap(HeapCreate(0, 0, 0))
	{ }

	~Garbage() {
		HeapDestroy(heap);
	}

} garbage;

void * operator new (size_t size) {
	return HeapAlloc(garbage.heap, 0, size);
}

void * operator new [](size_t size) {
	return HeapAlloc(garbage.heap, 0, size);
}

void operator delete(void *) {
}

void operator delete [](void *) {
}

sind es weniger als zwei Sekunden, also mehr als die 15-fache Leistung (was jedem beweisen sollte, dass man Hochleistungssysteme keinesfalls objektorientiert und/oder mit STL entwickeln darf). Der Unterschied im Speicherbedarf ist: 151 MiB statt 70. Die DLL wird dafür sagenhafte 120 KiB kleiner :shock:

Es stört mich irrsinnig, dass ich dafür die DLL benutzen muss, weil ich dynamische Bindung abgrundtief hasse. Aber für mich reicht das erstmal aus. Sagt mir bescheid, wenn ihr was Einfacheres einbaut, dann teste ich nochmal.

Ich hoffe, dass sich mein Gejammer nicht zu ruppig anhört; Assimp ist und bleibt eine gewaltige Erleichterung für mich :)

[kimmi]

Ich paste mal deine Lösung in den IssueReport. Der geht zwar nur unter Windows, allerdings als Denkansatz sehr sehr nützlch :). Und konstruktives Jammern, weil eine mögliche Lösung gleich mit aufzeigen ist immer erlaubt :).

Gruß Kimmi

[Krishty]

Okay. Füg bitte hinzu, dass es nur für die DLL-Version geht (sonst zerhaut man sich alle eigenen Allokatoren) und dass es unbedingt in einem eigenen Übersetzungsmodul liegen muss (sonst zerhaut man sich die Initialisierung globaler Variablen) :)