Ich evaluiere derzeit einige der skalierbaren Speicherzuordner, nedmalloc und ptmalloc (beide auf dlmalloc aufgebaut), als Ersatz für den Standard malloc / new wegen der erheblichen Konflikte in der Multithread-Umgebung. Ihre veröffentlichte Leistung scheint gut zu sein, aber ich möchte überprüfen, was Erfahrungen anderer Leute sind, die sie wirklich benutzt haben.
Ich habe NedMalloc in unsere Anwendung implementiert und bin sehr zufrieden mit den Ergebnissen. Die Konkurrenz, die ich vorher gesehen habe, war weg, und der Allokator war ziemlich einfach anzuschließen, sogar die allgemeine Leistung war sehr gut, bis zu dem Punkt, an dem der Overhead von Speicherzuweisungen aus ist, ist die Anwendung jetzt nahezu unmessbar.
Ich habe das ptmalloc nicht getestet, da ich keine Windows-fähige Version davon gefunden habe und ich die Motivation verloren habe, nachdem NedMalloc für mich gut funktioniert hat.
Abgesehen von den beiden genannten könnte es auch interessant sein, TCMalloc - es hat einige Funktionen, die besser klingen als NedMalloc in der Theorie (wie sehr wenig Overhead für kleine Zuweisungen, im Vergleich zu 4 B Header von NedMalloc verwendet), aber wie es scheint, nicht Windows-Port bereit zu haben, könnte es auch zu sein nicht gerade einfach.
Nach ein paar Wochen, in denen ich NedMalloc benutzt habe, war ich gezwungen, es aufzugeben, weil sein Platzbedarf sich für uns als zu hoch erwiesen hat. Was uns besonders beeindruckt hat, war, dass NedMalloc die Erinnerung, die es nicht mehr an das Betriebssystem gewöhnt ist, auf eine schlechte Art und Weise zurückfordert, wobei das meiste davon immer noch festgeschrieben wird. Für jetzt habe ich es durch JEMalloc ersetzt, was nicht so schnell zu sein scheint (es ist immer noch schnell, aber nicht so schnell wie NedMalloc war), aber es ist auf diese Weise sehr robust und seine Skalierbarkeit ist auch sehr gut.
Und nach ein paar Monaten mit JEMalloc habe ich zu TCMalloc gewechselt. Es hat mehr Aufwand erfordert, um es für Windows im Vergleich zu den anderen anzupassen, aber seine Ergebnisse (sowohl Leistung als auch Fragmentierung) scheinen für uns die besten zu sein, was ich bisher getestet habe.
In der Vergangenheit brauchte ich eine sehr schnelle Methode um Speicher zuzuordnen. Ich fand, dass es keine Zuteilung gab, die dem Job gewachsen war.
Nach ein paar Tagen Suche bin ich auf boost :: pool gestossen, was wir in unserer Applikation um 300x gesteigert haben.
Wir rufen gerade malloc / free für die Objekte auf, die wir erstellen wollen. Es gibt zwar einen kleinen Setup-Overhead, bei dem zu Beginn eine große Menge an Speicher mallokiert werden muss, aber sobald dies erledigt ist, ist dies sehr schnell.
Ich habe vor einiger Zeit versucht, Ihren Weg zu gehen, als Sie mit einer Multithread-Konkurrenz und einem schwerwiegenden Fragmentierungsproblem konfrontiert wurden. Nachdem ich ziemlich gründlich getestet hatte, kam ich zu dem Schluss, dass der Nutzen dieser Zuweiser in den meisten interessanten Fällen, die ich hatte, vernachlässigbar ist.
Die wirkliche Lösung war, meinen eigenen Speichermanager zu ziehen, der auf die Aufgaben spezialisiert war, die ich am häufigsten machte.
Wenn Sie mit Win32 arbeiten, ist es meiner Erfahrung nach schwierig, den normalen Windows-Heap-Manager zu übertreffen, vorausgesetzt, Sie aktivieren den Heapset mit der HeapSetInformation-API. Ich glaube, das ist jetzt Standard bei neueren Windows-Versionen. Es behandelt das Sperren mit Interlocked * Win32-Primitiven anstelle einfacherer Mutex / CritSec-Sperren.
Tags und Links c++ memory-management winapi multicore