Disk-backed STL-Container-Klassen? [geschlossen]

Question

Ich genieße die Entwicklung von Algorithmen der STL, aber ich habe dieses Problem wiederholt auftritt, wo meine Datensätze für den Heap zu groß ist.

Ich habe für Drop-in-Ersatz für STL-Containern und Algorithmen suchen, die scheiben gesichert sind, das heißt die Datenstrukturen auf der Festplatte gespeichert, anstatt dem Heap.

Ein Freund wies mich vor kurzem auf stxxl . Bevor ich auch mit ihm einlassen ... Ist anderer Disk-backed STL Ersatz zur Verfügung, die ich in Erwägung ziehen sollte?

Hinweis: Ich bin in der Persistenz oder Embedded-Datenbanken nicht interessiert. Bitte erwähnen nicht boost :: Serialisierung, POST ++, Relational Template Library, Berkeley DB, SQLite, etc. Ich bin mir bewusst, dieser Projekte und nutzen sie, wenn sie für meine Zwecke geeignet sind.

UPDATE: Mehrere Personen Speicher-Mapping-Dateien und die Verwendung eines benutzerdefinierten allocator erwähnt haben, gute Vorschläge BTW, aber ich würde sie auf die Diskussion hier wo David Abraham, dass Iteratoren Gewohnheit schlägt würde für Disk-backed-Container benötigt werden. die benutzerdefinierte allocator Ansatz Bedeutung ist wahrscheinlich nicht arbeiten.

Answer 1

Ich habe etwas, was sehr ähnlich umgesetzt. die Iteratoren Die Implementierung ist die größte Herausforderung. Ich benutzte boost :: iterator_facade die Iteratoren zu implementieren. Mit boost::iterator_facade Sie können anpassen einfach jede gecached auf Plattendatenstrukturen eine STL-Container-Schnittstelle haben.

Answer 2

Ich habe noch nie etwas zu tun, ganz so, aber es könnte möglich sein, zu tun, was Sie durch das Schreiben ein benutzerdefiniertes allocator tun mögen, dass Ihre Daten Verwendung eines Memory-Mapped-Dateien macht zu unterstützen.

Siehe boost :: interprocesses docs auf ihre einfache Implementierung von Speicher zu verwenden Mapped-Dateien, diesem Artikel Dr. Dobbs für eine detaillierte Diskussion über das Schreiben Verteilern und dieser IEEE Software Spalte für eine Beschreibung der Problem und Beispielcode .

Answer 3

Wenn (wie Sie schreiben) sind Sie in Persistenz nicht interessiert die einfachste Lösung, um Ihre Heap-Größe sein würde und Ihre virtuellen Speichereinrichtungen des Betriebssystems nutzen zu erhöhen. Der Teil des Haufens, die nicht in Ihrem Computer physischen Speicher passen wird am Ende wird auf der Festplatte ausgelagert, Ihnen genau zu geben, was Sie wollen: normal STL Zugriff auf den Daten häufig auf der Festplatte gespeichert. Das Betriebssystem kümmert sich um das Zwischenspeichern der am häufigsten verwendeten Seiten im physikalischen Speicher und vertreiben auf der Festplatte diejenigen, die Sie nicht viel nutzen. Ihr Code wird gleich bleiben, und Sie können seine Leistung einfach zu erhöhen, indem mehr physikalischen Speicher hinzugefügt wird.

Um die Heap-Größe überprüfen Sie Ihr Betriebssystem-Parameter zu erhöhen, wie ulimit (1) auf Unix-Systemen und Systemeigenschaften - Erweitert - Leistung - Erweitert - Virtueller Speicher unter Windows XP. Wenn Sie die 32-Bit-4GB Grenze betrachten den Übergang zu einer 64-Bit-Architektur getroffen haben oder die Erstellung Ihres Programms für 64 Bit.

Answer 4

Ich weiß nicht viel über das Thema, aber es könnte möglich sein, eine STL-ähnliche Schnittstelle zu einer Speicherabbilddatei zu schreiben?

edit: Dieser Ansatz könnte geeignet sein, wenn Sie an einem bestimmten Teil einer großen Datei zu erhalten versuchen. Wenn Sie versuchen, etwas mit der gesamten Datei zu tun, werden Sie wahrscheinlich eine große Anzahl von Seitenfehlern erzeugen, wie Sie in uncached Teilen der Datei lesen.