Pour le moment, j'utilise le modèle de conteneur de vecteur stl pour remettre et obtenir les connexions.
1) sur Obtenir, une connexion est renvoyée et "Effacer ()" D du vecteur de la piscine.
2) sur la libération, la connexion est remise à la piscine via "Push_back ()".
Cela pourrait être très lourd si la piscine est fréquemment utilisée. Donc, ma question est, existe-t-il un moyen d'améliorer la performance ici en passant à une autre structure de données?
3 Réponses :
garder le vecteur si vous connaissez le nombre maximum de connexions possibles à l'avance (voir vector :: réserve).
Sinon, utilisez STD :: Liste.
À la fin, cela dépend également de votre plate-forme et de la version du compilateur et de la libstdc ++ utilisé.
STD :: Liste signifie toutes les allocations pour chaque insert. Cela ne sera pas plus rapide que std :: vecteur .
vecteur est bien.
- Si vous adressez et effacez à la fois avant et arrière, mais jamais du milieu, utilisez
deque .
- Si vous devez fréquemment insérer dans et effacer à partir du milieu, utilisez la liste
.
- en fonction de vos besoins de recherche et de traversée,
définir pourrait être une alternative.
Dans tous les cas, vous devriez profil la performance; Utilisez un TypeDEF pour votre conteneur principal afin que vous puissiez changer rapidement et tester les différentes options.
Il peut y avoir d'autres exigences que vous ne nous indiquez pas mais qui sont importantes pour le choix du conteneur:
- vecteur et deque sont des conteneurs d'accès aléatoire; liste et définir sont basés sur des nœuds. Cela affecte l'invalidation de l'itérateur.
- Vector, Laqueque et la liste sont des conteneurs de séquence, tandis que défini est associatif; Cela affecte la recherche par la valeur.
J'ajouterais également que si l'OP n'efface pas de l'arrière, il devrait envisager cette approche (c'est-à-dire toujours pop_back et push_back ) - c'est une piscine, donc je suis Devinant qu'il n'y a pas commande et il peut être bénéfique de toujours utiliser le dernier article de toute façon ...
@Nim: Bon point - Je ne suis pas allé dans le problème de codage ambiant, mais (aussi comme dans la réponse de Juraj) échangeant des éléments autour de tout accès exclusivement à une extrémité est une bonne idée. Vecteur est le conteneur le plus simple et le plus économique, donc si la refonte de code le rend viable, c'est toujours une bonne chose.
Je sais que ce conseil est ce qui est traditionnellement donné, mais mes propres mesures suggèrent que ce n'est pas vraiment correct. Sauf si la copie est très coûteuse ( nouveau et Supprimer dans le constructeur de copie ou l'opérateur d'affectation), si le nombre typique d'éléments n'est pas trop grand, std :: Vecteur battra tous les autres. Et la seule raison pour toujours utiliser std :: list est d'éviter l'invalidation de l'itérateur. Le manque de localité tue tout avantage de performance qu'il aurait pu autrement.
@James: Très plausible - c'est pourquoi vous devez profiler :-) Les garanties asymptotiques ne disent malheureusement rien sur le comportement du monde réel!
std :: vecteur est probablement le meilleur conteneur pour la piscine. O (1) pour l'insertion et vous pouvez également avoir O (1) pour l'élimination si vous n'avez pas besoin de maintenir la commande. Vous pouvez simplement échanger le dernier élément avec l'élément retiré et rétrécir le vecteur. Aussi std :: vecteur est assez spatial efficace que d'autres conteneurs. La consommation faible de la mémoire signifie également une meilleure performance en raison de plusieurs hits de cache CPU.
Les goulots d'étranglement rarement sont si nous supposons qu'elles soient, le profilage est donc bien meilleur que d'essayer d'optimiser avec sans espoir.
Bien sûr, le profilage. Mais conceptuel vu c'est la bonne approche en utilisant un conteneur, je suppose ...