Version imprimable
Bonjour.
J'ai une petite question pour des experts ;). Combien pèze/coute un std::vector ?
ex:
Si on a un objet dans un autre objet, et qu'on le transforme en vector ( pour le cas ou ), alors que cet objet est voué à être reproduit en ( relative ) grande quantité. Cela peut-il faire un différence concrète ( ralentissement notable du programme ) , selon vous ? cela dépend-it également de la taille de l'objet a mettre en vector ?
Merci si vous pouvez répondre :)
Trop vague !!!
ok, rien que cette réponse m'éclaire un peu (mais pas forcément dans le bon sens pour moi :aie:).
dans mon cas, j'ai une entité Graphics, contenue dans un objetX. Cet objetX peut également être un objetY, ou un objetZ etc...il contiennent la même entité Graphics. maintenant, cet objetX, il va être multiplié, en tant par exemple, qu'élément de décor, ou encore petit objet animé etc..Seulement parfois, cet objetX, il pourrait contenir plusieurs Graphics, mais parfois non. (ça m'arrange d'avoir un ObjetX qui puisse être construit de différentes façons, tout en restant un objetX).
Donc, si je met, dans mon objetX, un std::vector < Graphics > au lieu d'un simple Graphics, même si la plupart du temps, seul le std::vector < Graphics >::iterator it = _monVectorGraphics.begin() ; serait utilisé, les performance pourraient-elles être réduites de façon conséquentes selon vous ? Sachant que l'objet est appelé constamment.
Toujours très très vague, mais on va essayer de faire des supputations "logiques". :weird:
Oui, l'accès à un élément d'un vector est moins rapide que d'avoir l'objet directement sous la main, vu qu'il y a une indirection.
Mais avoir un ou plusieurs "Graphics", c'est pas du tout la même chose.
Mais bon, c'est le genre de considération facilement paramétrable par des Stratégies et autres Design Pattern.
Ok, merci.
de façon conséquente ou négligeable ?Citation:
Oui, l'accès à un élément d'un vector est moins rapide
Je vais essayer de citer un exemple plus précis :
J'ai une scène, qui va comporter 500 objets ( voir plus ). Chacun d'eux contient un objet "Graphics" qui va être "updaté" a chaque boucle ( ou toutes les 1/16ème de secondes dans mon cas ). Ils peuvent de plus être appelés par d'autres objets pour effectuer des changements dans le même temps.
Si, au lieu de mettre un objet Graphics, je met un std::vector < Graphics > , mais pour le même usage. Cela est-t-il, selon vous, susceptible de ralentir le programme ou de consommer plus de ressources de façon conséquente, ou même simplement notable ( pour un ordinateur normal ) ?
EDIT :
En somme, pour etre plus explicite, j'aurais besoin d'objets qui pourraient avoir ( pour certains ) plusieurs entités d'images qu'ils pourraient superposer ( exemple, lorsque le joueur déclenche une action, une animation supplémentaire vient se poser au dessus de celle déjà en place. )
Voila pourquoi je me suis dit : a la limite, autant changer l'entité en vector d'entité affin de pouvoir en implémenter autant que nécessaire, et ainsi les gérer ( animation etc... ) plus facilement.
Mais je pourrais tout aussi bien complexifier un peu mon entité Graphics , afin de lui faire gérer plus de choses.
Avez vous une idée/conseil sur ce qui serait préférable?
La façon dont tu poses la question montre que tu n'as pas assez de recul sur ce type de problématique. (et c'est pourquoi bacelar n'a pas d'autre choix que de répondre au final "cela dépend")
Tu te focalises sur une "mesure" absolue de la performance, ce qui n'a pas de sens. Un solution technique n'a de sens que comparer aux autres solutions possibles, dans un contexte donné.
Si tes "Graphics" ne font que remplir un vertex buffer pré alloué, que tu utilises une vector<Graphics> dans chaque classe et que tu parcours 500 objets, tu pourras avoir un coût négligeable avec ces vector.
Tu fais la même chose sans vector, avec une classe Graphics qui utilise des setPixel en direct mode, même sans vector<Graphics> dans tes classes, tes performances seront probablement moisies.
On n'évalue pas des performances dans l'absolue. On évolue des performances sur un code réel, avec du profiling. On compare différente solutions techniques pour trouver la plus optimale, c'est à dire celle qui aura le "meilleur" compromis entre performance, robustesse, évolutivité, etc. (sachant que chacun a ses propres critères pour ce qu'il estime être le meilleur)
Prend la solution la plus simple, implémente là, écrit du code "propre" et testes les performances. Ensuite, testes d'autres solutions