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

Question

Je travaille sur une bibliothèque informatique à très grande échelle qui utilise fortement STL. La bibliothèque est construite avec MSVC2003 et utilise son implémentation STL. Je recherche une autre implémentation STL qui aiderait la bibliothèque à réduire ses besoins en mémoire et à augmenter ses performances.

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

Je voudrais des commentaires sur l'utilisation dans le monde réel qui ne soient pas basés sur des points de repère, si possible.

EDIT: Pour clarifier un peu, par exemple, certaines implémentations STL (comme STLSoft) proposent des optimisations spécifiques pour la concaténation de chaînes; Celles-ci peuvent avoir un impact mineur, mais elles peuvent conduire à de grandes améliorations. STLPort est un autre bon exemple où ils énoncent clairement leur objectif: avoir la mise en œuvre la plus rapide de STL, il existe stdlib ++, etc ... tous peuvent être de bons candidats mais je n'ai pas le temps de les tester tous, j'ai besoin de l'aide de la communauté sur cela.

Answer 1

STLPort . Nous n'avons pas mesuré les différences d'utilisation de la mémoire, mais c'est nettement plus rapide (oui, utilisation dans le monde réel).

Answer 2

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

Je ne pense pas que vous obtiendrez une mémoire insuffisante et des performances accrues "gratuitement". en téléchargeant une nouvelle 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 souhaitez mettre à jour ... faites-le maintenant et vous pourriez avoir de la chance et bénéficier gratuitement de cette mémoire et de ces performances.

La seule chose que je puisse penser à vous suggérer dans le sens de ce que vous dites rechercher serait d'essayer le compilateur Intel, que j'ai eu à la fois bon (performance!) et mauvais (original, parfois !) expérience avec.

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

Answer 3

Avez-vous envisagé d’écrire votre propre allocateur de mémoire? Si vous n’aimez tout simplement pas la stratégie d’allocation de mémoire, vous n’avez pas toujours besoin de changer l’ensemble de la STL. Tous les conteneurs acceptent un allocateur de remplacement.

Answer 4

Avez-vous défini votre code et envisagé de petits ajustements aux zones qui posent problème? Je pense que ce serait beaucoup moins pénible que ce que vous envisagez.

Answer 5

Tout dépend du conteneur dont vous parlez et de la façon dont vous l’utilisez. vector a généralement la plus petite empreinte, sauf qu'au moment où vous ajoutez un élément dépassant la capacité vectorielle actuelle. À ce moment, il allouera environ 1,5 fois la capacité actuelle des vecteurs, déplacera les éléments (ou, dans le pire des cas, créera une nouvelle copie allouant également de la mémoire) et, le cas échéant, supprimera les anciens vecteurs internes. Si vous savez comment de nombreux éléments qu’il va conserver à l’avant, la meilleure solution est d’utiliser un vecteur.

La deuxième plus petite est la liste. Il a l'avantage de ne pas faire une copie temporaire de lui-même. Après cela, votre meilleur pari est probablement défini. Certaines mises en œuvre ont maintenant lieu, ce qui est plus petit. Dans ces cas, il est assez facile de créer un allocateur qui emballe la mémoire en pages. Éloignez-vous de la mémoire des porcs comme unordered_ *

Sur MSVC, assurez-vous de #define _SECURE_SCL = 0 Ceci supprime beaucoup de temps système utilisé pour les contrôles de programmation sécurisés (comme les dépassements de mémoire tampon, etc.)

De loin, les conteneurs les plus efficaces en termes de mémoire sont boost / intrusifs. Ils ont une empreinte de pas extrêmement réduite car ils utilisent la mémoire de la chose en cours de stockage. Donc, plutôt que d’aller dans le tas pour un petit bloc de mémoire pour une liste liée ou un nœud d’arbre rb, les pointeurs de nœud font partie de l’objet même. Puis le " conteneur " est juste un ensemble brut de quelques pointeurs pour faire un nœud racine. Je l'ai utilisé plusieurs fois pour éliminer l'encombrement et les frais généraux liés à l'allocation.

Answer 6

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 mise en œuvre à l'autre.

Cependant, vous pouvez parfois écrire un algorithme (ou un conteneur) plus rapide que la STL car vous savez quelque chose à propos de vos données que le rédacteur de STL n'a pas créé (car ils écrivaient des conteneurs et un algorithme génériques).

En conclusion, si vous souhaitez améliorer les performances de vos applications, essayez de créer des conteneurs spécialisés qui s'adaptent à vos données, plutôt que de rechercher un STL plus performant.

Answer 7

Si les performances sont si essentielles pour votre application et que STL y est intimement lié, est-il possible de trouver une implémentation à source ouverte (telle que STL-Port , comme mentionné) et le créer vous-même, en améliorant les performances si nécessaire?

D'un côté, je peux voir que cela devient une pente glissante dans laquelle vous apportez des modifications non standard à votre branche de la bibliothèque STL, ce qui crée des problèmes. Toutefois, l’importance des performances pour votre application peut compenser le risque que cela se produise.