Bonjour,
question originale :
La STL est-elle adaptée pour du code critique en termes de performance ?
En ce qui concerne l'argument selon lequel les différents compilateurs fournissent des versions différentes, je pense que ce n'est pas un bon argument : STLport est justement faite pour corriger cela.
Sinon du point de vu général :
A/
Si les performances sont déjà suffisantes, pourquoi pas?
B/
Il est souvent facile d'écrire des conteneurs plus performants que la STL en terme de performance (c'est d'ailleurs assez déroutant:aie:). Pour cela, il ne faut cependant de ne pas reposer sur les hypothèses de fonctionnement qui sont justement à la source de ses défauts. Par exemple, il est préférable d'utiliser swap() au lieu de constructeurs par recopie etc... Cependant, même si c'est facile, cela peut prendre du temps d'écrire cette solution.
Une solution meilleure encore est d'utiliser des librairies dont on sait qu'elles sont plus performantes que la STL avec une interface quasiment identique, et proposant plusieurs kernels justement pour s'adapter au besoin. Il suffit de tester la librairie dlib (et ses conteneurs) dispo sur sourceforge pour s'en convaincre.
J'ajoute que l'introduction de la move-semantic du C++11 est une manière -de mon point de vue- de chercher à corriger ce problème de la STL. C'est comme ajouter un pansement sur une blessure qu'on aurait pu éviter.
Ensuite, pour les performances, il ne faut pas négliger :
1/ les algorithmes
2/ les instructions spécifiques du processeur (sse par exemple, memcmp, ... ). Voire exécuter un shader sur GPU:ccool:.
3/ l'assembleur
Cordialement,
ElPedro
EDIT : Je viens de lire le thread original. Pour des performances celui qui veut faire du traitement d'image, sera plus performant en vitesse d'exécution s'il passe par une texture + shaders sur GPU! En faisant une acquisition directe sur la carte graphique (certain drivers l'autorisent), il économisera aussi la RAM de la texture - et en perdra au niveau des librairies de contrôle du GPU qui seront chargées.
