Welches ist die STL-Implementierung mit dem geringsten Speicherbedarf?

Question

Ich arbeite an einer sehr umfangreichen Computerbibliothek, bei der STL stark genutzt wird. Die Bibliothek wird mit MSVC2003 erstellt und verwendet dessen STL-Implementierung. Ich bin auf der Suche nach einer alternativen STL-Implementierung, die der Bibliothek helfen würde, ihren Speicherbedarf zu senken und ihre Leistung zu steigern.

Ein Wechsel zu einer neueren Version von MSVC ist im Moment nicht möglich.

Ich hätte gerne ein Feedback über die reale Nutzung und nicht über Benchmarks, wenn möglich.

EDIT: Um es ein wenig klarer zu machen, schlagen zum Beispiel einige STL-Implementierungen (wie STLSoft) spezielle Optimierungen für die String-Verkettung vor; diese mögen sich in ihren Auswirkungen gering anhören, können aber zu großen Verbesserungen führen. STLPort ist ein weiteres gutes Beispiel, wo sie ihr Ziel klar formulieren: die schnellste STL-Implementierung zu haben, es gibt stdlib++, usw. ... all diese können gute Kandidaten sein, aber ich habe keine Zeit, sie alle zu testen, ich benötige dazu die Hilfe der Community.

Answer 1

STLPort . Ich habe die Unterschiede in der Speichernutzung nicht gemessen, aber es ist definitiv schneller (ja, in der Praxis).

Answer 2

Ich stelle Ihre Grundannahme in Frage, dass Sie nicht zu einer neueren Version von MSVC wechseln können.

Ich glaube nicht, dass Sie durch das Herunterladen einer neuen STL einen geringeren Speicherbedarf und eine höhere Leistung "umsonst" erhalten werden. Oder zumindest, wenn Sie es taten, müssten Sie wahrscheinlich so viele Codekorrekturen vornehmen, wie wenn Sie einfach auf die neueste MSVC aktualisieren würden.

Langfristig ist es keine Frage, dass Sie aktualisieren wollen... Tun Sie es jetzt, und Sie pourrait Glück haben und etwas von dem Speicher und der Leistung umsonst bekommen.

Das Einzige, was ich Ihnen vorschlagen kann, wäre, den Intel-Compiler auszuprobieren, mit dem ich sowohl gute (Leistung!) als auch schlechte (seltsam, manchmal!) Erfahrungen gemacht habe.

Andernfalls müssen Sie Ihre eigenen Speicher- und Leistungsprobleme finden und eigene Container und Algorithmen schreiben. Die STL ist großartig, aber sie ist kein Allheilmittel, um alle Probleme in allen Fällen zu lösen. Fachwissen ist Ihr bester Verbündeter.

Answer 3

Haben Sie schon einmal daran gedacht, einen eigenen Speicherzuweiser zu schreiben? Sie müssen nicht immer die gesamte STL austauschen, wenn Ihnen die Speicherzuweisungsstrategie nicht gefällt. Alle Container akzeptieren einen Ersatz-Allokator.

Answer 4

Haben Sie ein Profil Ihres Codes erstellt und überlegt, ob Sie die Bereiche, die das Problem darstellen, ein wenig optimieren können? Ich würde denken, das wäre viel weniger schmerzhaft als das, was Sie in Erwägung ziehen.

Answer 5

Das meiste hängt davon ab, von welchem Container Sie sprechen und wie Sie ihn verwenden. vector hat normalerweise den kleinsten Platzbedarf, es sei denn, Sie fügen ein Element hinzu, das die aktuelle Vektorkapazität übersteigt. In diesem Moment wird es etwas wie 1,5 x die aktuelle Vektorkapazität zuweisen, verschieben Sie die Elemente (oder im schlimmsten Fall eine neue Kopie, die auch Speicher zuweist) und wenn das getan ist, löschen Sie die alten Vektoren Interna, Wenn Sie wissen, wie viele Elemente es geht, um im Voraus zu halten, Vektor mit einer Verwendung von Reserve ist Ihre beste Wette.

Die zweitkleinste ist die Liste. Sie hat den Vorteil, dass sie keine temporäre Kopie von sich selbst erstellt. Danach ist set wahrscheinlich die beste Wahl. Einige Implementierungen haben jetzt slist, das kleiner ist. In diesen Fällen ist es ziemlich einfach, einen Allokator zu erstellen, der den Speicher in Seiten packt. Halten Sie sich von Speicherfressern wie unordered_* fern.

Unter MSVC muss #define _SECURE_SCL=0 gesetzt werden. Dadurch wird ein Großteil des Overheads entfernt, der für die Überprüfung der sicheren Programmierung verwendet wird (wie Pufferüberläufe usw.)

Die bei weitem speichereffizientesten Container sind boost/intrusive. Diese haben einen extrem kleinen Fußabdruck, da sie den Speicher des enthaltenen Objekts nutzen. Anstatt also im Heap einen kleinen Teil des Speichers für eine verknüpfte Liste oder einen rb-Baumknoten zu suchen, sind die Knotenzeiger Teil des Objekts selbst. Dann ist der "Container" nur ein roher Satz von ein paar Zeigern, um einen Root-Knoten zu machen. Ich habe es ziemlich oft verwendet, um den Footprint und den Zuweisungs-Overhead loszuwerden.