Quelle est l'implémentation STL avec l'empreinte mémoire la plus faible?

Question

Je travaille sur une bibliothèque informatique à très grande échelle qui utilise beaucoup STL. La bibliothèque est en cours de construction à l'aide de MSVC2003 et utilise son implémentation STL. Je suis à la recherche d'une implémentation STL alternative qui aiderait la bibliothèque à réduire ses besoins en mémoire et à augmenter ses performances.

Il n'est pas possible de passer à une version plus récente de MSVC pour le moment.

J'aimerais avoir des commentaires sur l'utilisation dans le monde réel qui ne sont pas basés sur des tests de performance si possible.

EDIT: Pour le rendre un peu plus clair, par exemple certaines implémentations STL (comme STLSoft) proposent des optimisations spécifiques pour la concaténation de chaînes; Ceux-ci peuvent sembler faibles mais ils peuvent mener à de grandes améliorations. STLPort est un autre bon exemple où ils indiquent clairement leur objectif: avoir l'implémentation STL la plus rapide, il y a le stdlib ++, etc ... tous ces candidats peuvent être de bons candidats mais je n'ai pas le temps de les tester tous. sur ça.

Answer 1

STLPort. N'a pas mesuré les différences d'utilisation de la mémoire, mais c'est certainement plus rapide (oui, l'utilisation du monde réel).

Answer 2

Je remets en question votre prémisse de base, que vous ne pouvez pas passer à une version plus récente de MSVC.

Je ne pense pas que vous obtiendrez moins de mémoire et des performances accrues "gratuitement" en téléchargeant un nouveau STL. Ou du moins, si vous le faisiez, vous auriez probablement à faire autant de corrections de code que si vous deviez simplement mettre à jour le dernier MSVC.

À long terme, il ne fait aucun doute que vous voulez mettre à jour ... Faites-le maintenant, et vous pourrait avoir de la chance et obtenir une partie de cette mémoire et la performance gratuitement. La seule chose que je peux penser à vous suggérer dans le sens de ce que vous dites que vous cherchez serait d'essayer le compilateur Intel, que j'ai eu à la fois bon (performance!) Et mauvais (excentrique, parfois!) expérience avec.

À part cela, trouvez vos propres problèmes de mémoire et de performance, et écrivez des conteneurs et des algorithmes personnalisés. STL est génial, mais ce n'est pas une panacée pour résoudre tous les problèmes dans tous les cas. La connaissance du domaine est votre meilleur allié.

Answer 3

La plupart des implémentations STL, y compris celle de MSVC2003, sont des bibliothèques génériques bien implémentées. Vous ne verrez donc pas d'amélioration significative des performances d'une implémentation à l'autre. Cependant, vous pouvez parfois écrire un algorithme (ou un conteneur) plus rapide que la STL pour vous parce que vous savez quelque chose à propos de vos données que l'éditeur STL n'a pas changé (puisqu'il écrivait des conteneurs et des algorithmes génériques). En conclusion, si vous voulez améliorer les performances de vos applications, mieux vaut essayer de créer des conteneurs spécialisés adaptés à vos données, plutôt que de chercher une STL plus performante.

Answer 4

Si les performances sont si importantes pour votre application et que STL y est imbriqué, est-il possible de trouver une implémentation open-source (comme STL-Port, comme mentionné) et de l'améliorer? D'une part, je peux voir que cela devient une pente glissante où vous faites des modifications non standard à votre fourche de la bibliothèque STL, créant ainsi des problèmes.Cependant, l'importance des performances pour votre application peut l'emporter sur le risque que cela se produise.

Answer 5

Avez-vous envisagé d'écrire votre propre allocateur de mémoire? Vous n'avez pas toujours besoin de changer la STL entière si vous n'aimez pas la stratégie d'allocation de mémoire. Tous les conteneurs acceptent un allocateur de remplacement.

Answer 6

Avez-vous profilé votre code et considéré de petits réglages sur les zones qui posent problème? Je pense que ce serait beaucoup moins douloureux que ce que vous envisagez.

Answer 7

La plupart dépendent du conteneur dont vous parlez et de la façon dont vous l'utilisez. Le vecteur a généralement la plus petite empreinte, sauf qu'au moment où vous ajoutez un élément qui dépasse la capacité vectorielle actuelle. A ce moment il va allouer quelque chose comme 1.5 x la capacité actuelle des vecteurs, déplacer les éléments (ou dans le pire des cas faire une nouvelle copie qui alloue également de la mémoire) et quand cela est fait, supprimer les anciens vecteurs internes, Si vous savez de nombreux éléments qu'il tiendra à l'avant, vecteur avec une utilisation de réserve est votre meilleur pari.

Le deuxième plus petit est la liste. Il a l'avantage qu'il ne va pas faire une copie temporaire de lui-même. Après cet ensemble est votre meilleur pari est probablement fixé. Certaines mises en œuvre ont maintenant une coupe, qui est plus petite. Dans ces cas, il est assez facile de créer un allocateur qui empaquette la mémoire dans les pages. Éloignez-vous des porcs de mémoire comme unordered_ *

Sur MSVC assurez-vous #define _SECURE_SCL = 0 sort beaucoup de frais généraux utilisés pour les contrôles de programmation sécurisés (comme les dépassements de mémoire tampon, etc.)

De loin le plus Les conteneurs à mémoire efficace sont boost/intrusifs Ils ont des empreintes de pas extrêmement petites puisqu'ils utilisent la mémoire de la chose contenue. Donc, si vous voulez aller au tas pour un petit morceau de mémoire pour une liste chaînée ou un nœud d'arbre rb, les pointeurs de nœuds font partie de l'objet lui-même. Ensuite, le "conteneur" est juste un ensemble brut de quelques pointeur pour faire un nœud racine. Je l'ai utilisé plusieurs fois pour se débarrasser de l'empreinte et des frais généraux d'allocation.