Classes de conteneur STL sauvegardées sur disque?

Question

J'ai plaisir à développer des algorithmes de la STL, cependant, j'ai ce problème récurrent où mes ensembles de données sont trop gros pour le tas.

J'ai été la recherche de substituts pour les conteneurs STL et les algorithmes qui sont disque de sauvegarde c'est à dire les structures de données stockées sur le disque plutôt que le tas.

Un ami a récemment m'a orienté vers stxxl. Avant que je sois trop impliqués avec elle... Sont tout autre disque adossés à des TSL, les remplacements que je devrait prendre en considération?

NOTE: je ne suis pas intéressé à la persistance ou à des bases de données. Veuillez ne pas parler de boost::serialization, POST++, Relationnelle Modèle de Bibliothèque, Berkeley DB, sqlite, etc. Je suis au courant de ces projets et de les utiliser quand ils sont appropriés pour mes fins.

Mise à JOUR: Plusieurs personnes ont évoqué la mémoire de fichiers de mappage et utilisation d'un personnalisé programme d'allocation de bonnes suggestions à ce propos, mais je tiens à souligner à la discussion là où David Abraham suggère que la coutume des itérateurs seraient nécessaires pour disque adossés à des conteneurs. Sens de l'allocateur personnalisé approche n'est pas susceptible de travailler.

Answer 1

J'ai mis en place quelque chose de très similaire. La mise en œuvre des itérateurs est la plus difficile. J'ai utilisé boost :: iterator_facade pour implémenter les itérateurs. En utilisant boost::iterator_facade vous pouvez facilement adapter les structures de données de disque mises en cache à une interface de conteneur STL.

Answer 2

Je n'ai jamais eu à faire quelque chose de tout à fait comme cela, mais Il pourrait être possible de faire ce que vous voulez faire par la rédaction d'un allocateur personnalisé qui rend l'utilisation de l'un des fichiers mappés en mémoire pour sauvegarder vos données.

Voir boost::interprocesses pour les docs sur leurs facile à utiliser mise en œuvre de fichiers mappés en mémoire, ce Dr Dobbs article pour une discussion détaillée sur l'écriture allocateurs, et ce IEEE Logiciel de colonne pour une description du problème et de l' exemple de code.

Answer 3

Si (comme vous l'écrivez), vous n'êtes pas intéressé par la persistance de la solution la plus simple serait d'augmenter votre taille de segment de mémoire et l'utilisation de votre système d'exploitation mémoire virtuelle des installations. La partie du tas qui ne rentrent pas dans le physique de votre ordinateur mémoire sera à la fin paginée sur le disque, de vous donner exactement ce que vous voulez: normal STL accès aux données stockées sur le disque. Le système d'exploitation s'occupera de la mise en cache de la plupart des pages dans la mémoire physique et d'expulsion de disque ceux que vous n'utilisez pas beaucoup. Votre code reste le même, et vous pouvez augmenter ses performances tout simplement en ajoutant plus de mémoire physique.

Pour augmenter votre taille de tas de vérifier votre système d'exploitation paramètres, comme ulimit(1) sur les systèmes Unix et les propriétés du Système - Avancé - Performance - Avancé - la Mémoire Virtuelle sous Windows XP. Si vous avez touché le 32 bits limite de 4 go envisager de passer à une architecture en 64 bit ou de la compilation de votre programme pour la version 64 bits.

Answer 4

Je ne connais pas grand chose à ce sujet, mais il serait peut-être possible d'écrire une interface de type STL dans un fichier mappé en mémoire?

edit: Cette approche peut convenir si vous essayez d’obtenir une partie spécifique d’un fichier volumineux. Si vous essayez de faire quelque chose avec le fichier entier, vous allez probablement générer un grand nombre de fautes de page en lisant des parties non mises en cache du fichier.