La lenteur d'allocation / désallocation en c++ n'est pas vraiment un scoop. Les objets vector, en tiennent évidement compte pour effectuer une gestion très optimisée de la mémoire. Maintenant, lorsque j'écris un morceau critique de code, je ne sais pas vous, mais moi, je n'y met naturellement pas de new. Si vous faites de l'algorithmique, vous vous rendez bien compte que lorsqu'un algorithme demande de l'allocation de mémoire dynamique (Réelement dynamique, je me demande si certains codeurs n'ont pas oublié ce qu'était l'allocation statique - je ne parle pas pour les posteurs présents) c'est un problème auquel l'on s'intéresse avec ardeur. Et lorsque l'on s'intéresse à ce genre de problème on peut faire sans problème aussi bien qu'un Garbage Collector.

Il est évident, que sur un gros projet on ne va pas s'ennuyer à se demander toujours "Quelle est la manière la plus optimisée d'allouer la mémoire". Mais si on parle de performences, il convient il me semble de s'intéresser à des applications qui recquierent de la performences.

Optimisation avec le SSE2 ? Elles sont rarement efficaces. Mais je vous croirai si vous me montriez un algorithme capable détecter dans quel morceau d'un code il est judicieux de calculer quatre racines carrées en même temps. Pour toute autre optimisation "systématique" grace à ces instructions, je suis preneur. (Je connais surtout les optimisations non-systématiques, ou celles utilisées dans des fonctions de copie de mémoire)

Il existe un exemple trivial, capable de décerner C++ gagnant. Il suffit de coder un programme en C++ qui a son propre optimiseur JIT. Ca paraît stupide, mais je pense que l'exemple est important. Vous pouvez toujours optimiser plus, en passant par l'assembleur. J'ai battu énormément de compilateurs à ce jeu, pour une improductivité impressionante. En d'autres termes, il est plus intéressant de s'intéresser à un rapport Productivité / Performence, et de choisir lequel nous intéresse pour quel but. Mais cette idée est déjà omniprésente dans ce post.