Schnellere Heap Implementierung für MSVC gesucht
-
Wenn Du viele Allokationen hast fragmentiert dieser nicht so und ist somit wesentlich schneller
-
Ah. Das auch logisch klingen tun
Die zentrale "eine für alle Threads" Critical-Section die bei jeder Heap Allocation gelockt werden muss gibt's aber immer noch, oder?
(Also im Gegensatz zu Allokatoren wie dem tcmalloc und ähnlichen Biestern)Und... zahlt es sich aus mit der _set_sbh_threshold() Funktion rumzuspielen, oder ist das vergebene Liebesmüh'?
-
AFAIK wird der sbh ab VS2005 nicht mehr verwendet... und wenn Du den LFH verwendest kommen sich die beiden eh nur die die Quere! ALso bitte nicht einschalten!
-
Ja, in deinem 2. Link steht dass der SBH "Schwellwert" bei VC8 per Default 0 ist, was den SBH deaktiviert.
Hatte mir schon fast gedacht dass SBH + LFH = nicht so gute Idee
-
Im Übrigen erstmal Danke, Jochen!
Hab jetzt nochwas selbst gefunden:
http://stackoverflow.com/questions/858592/windows-malloc-replacement-e-g-tcmalloc-and-dynamic-crt-linkingDer "nedalloc" sieht interessant aus:
http://www.nedprod.com/programs/portable/nedmalloc/
-
Hmpf.
Der "nedmalloc" mag mich nicht.
Da ist ne fertige DLL dabei, aber die funktioniert nicht - zumindest nicht mit dem "windows patcher".
Die Patch-Funktion gibt "1" zurück, aber es wird nix schneller in meinem kleinen Benchmark-Programm.Wenn ich dagegen den LFH aufdrehe wird es merklich schneller.
Hmpf.
@Jochen
Spricht etwas dagegen das LFH Flag auch für den "Process-Heap" aufzudrehen?
Ich verwende den Process-Heap selbst nicht, aber vielleicht gibt es ja diverse Windows DLLs die sich da bedienen - dachte mir wenn dann gleich bei beiden Heaps.
-
Der LFH kann man normal für alle Heaps verwenden... wüsste nicht was dagegen sprechen sollte...
-
Warum genau müsst ihr denn so viel allokieren? Sind das vielleicht lauter gleichartige Objekte?
-
Weil das eben so ist
Und nein, einfach nen Pool reinwerfen ist nicht.Da läuft ein Prozess. In den werden bei bedarf DLLs reingeladen. Jede DLL ist ein Spiel. Wenn der Spieler Spiel wechselt wird die DLL rausgeworfen und ein neues Spiel (andere DLL) geladen.
Jedes Spiel baut sich seinen Szenen-Graphen komplett neu auf, mitsamt der vielen tausend Objekte die man dazu braucht.
Es werden std::vector und std::string verwenden und auch ab und an mal rumkopiert/returned/... (speziell Strings).
Dinge ebenDa anzufangen irgendwas umzuschreiben ist nicht. Das sind viele viele VIELE Projekte (LIBs, DLLs, ein paar EXEn) mit insgesamt vermutlich weit über 200 KLOC.
Und da das ganze nach ein paar Spiel-Wechseln anfängt langsamer zu werden, liegt die Vermutung nahe, dass da was fragmentiert. (Vor allem da der Handle-Count, Speicherverbrauch etc. sich halbwegs gut auf einem Wert einpendelt - echtes Leak ist hier also eher keines am Werk). LFH könnte schon mal helfen - am echten Patienten konnte ich es noch nicht probieren. Und wenn der Allocator nebenbei zusätzlich schneller wird, wäre das natürlich ein zusätzlicher Bonus.
Davon abgesehen war mir der doch relativ langsame Allocator von MSVC immer schon ein Dorn im Auge. Wobei sich ja jetzt herausgestellt hat, dass hier nicht MSVC Schuld ist, sondern unser betagtes Windows XP.
Insbesondere da ich weiss, dass es schon länger wesentlich schnellere Allocator gibt - tcmalloc, ptmalloc etc. Darum will ich auch gar nicht wahnsinnig viel Zeit in etwas investieren (=manuell zu poolen anfangen oder was weiss ich), was eigentlich nicht nötig ist, und spätestens mit dem angeblich turboschnellen Allocator von Windows 7 keinen Sinn mehr machen wird. Weil man dabei kaum noch was gewinnt.
----
Da nedmalloc zumindest behauptet mit den schnellsten Allokatoren mithalten zu können, dachte ich mir das wäre ne feine Sache. WENN ich es denn zum Laufen bringen würde
-
hustbaer schrieb:
Und da das ganze nach ein paar Spiel-Wechseln anfängt langsamer zu werden, liegt die Vermutung nahe, dass da was fragmentiert. (Vor allem da der Handle-Count, Speicherverbrauch etc. sich halbwegs gut auf einem Wert einpendelt - echtes Leak ist hier also eher keines am Werk).
Besteht vielleicht die Möglichkeit jeder dll ihren eigenen Heap zu geben und den beim Spielwechsel einfach komplett wegzuwerfen?
Oder könnte man jede dll vielleicht in einem separaten Prozess hosten, statt alle im selben?
-
dot schrieb:
hustbaer schrieb:
Und da das ganze nach ein paar Spiel-Wechseln anfängt langsamer zu werden, liegt die Vermutung nahe, dass da was fragmentiert. (Vor allem da der Handle-Count, Speicherverbrauch etc. sich halbwegs gut auf einem Wert einpendelt - echtes Leak ist hier also eher keines am Werk).
Besteht vielleicht die Möglichkeit jeder dll ihren eigenen Heap zu geben und den beim Spielwechsel einfach komplett wegzuwerfen?
Nö.
Wüsste nicht wie ich das dem MSVC beibringen sollte. Ausserdem haben die DLLs C++ Interfaces, und es ist nicht garantiert dass alles was die DLL alloziert auch mit ihr sterben geht.Oder könnte man jede dll vielleicht in einem separaten Prozess hosten, statt alle im selben?
Ja, mit gröberen Umbauarbeiten = no-go im Moment.
-
Schon mal daran gedacht in kritischen Klassen einen Pool-Allokator zu verwenden?
