2010-12-10 26 views
9

Beaucoup de profilage montre que les flux C++ ne sont pas la meilleure façon d'effectuer une manipulation de chaîne de fichier ou de texte lorsque la performance (vitesse) est requise. Pourtant, les flux standards sont un bon moyen de garder les choses sûres. D'après ce que j'ai lu, la plupart du problème est dû au fait que les implémentations de flux doivent 1) créer/copier beaucoup de petits objets 2) arnt entièrement génériques (ne pas gérer char et wchar de la même façon?) Etc Quoi qu'il en soit, je pensais que peut-être que C++ 0x permettrait aux développeurs de limiter au moins la création/copie d'objets et peut-être que d'autres fonctionnalités permettraient d'améliorer les performances, permettant d'atteindre les performances printf() ?Est-ce que les références C++ 0x RValue ou d'autres fonctionnalités auront un impact sur les performances des flux?

Y a-t-il un impact immédiat? Ou faudra-t-il attendre de nouvelles implémentations? Ou avons-nous encore besoin d'une nouvelle bibliothèque de flux (similaire à STL)?

+0

Juste une note de côté sur le sujet. Je suis d'avis que les bibliothèques IO sont super difficiles à concevoir. Je voudrais que quelqu'un pointe une bibliothèque IO dans n'importe quelle langue qui soit 1) sûre, 2) efficace, 3) portable et 4) utilisable par un programmeur moyen (comme moi par exemple!). Je ne dis pas que concevoir un avec les conditions ci-dessus est impossible, je dis juste qu'il est plus dur que ce que la plupart des programmeurs pensent. Btw, +1 pour la question. – AraK

+0

Je suis d'accord. Je suppose que c'est la principale raison pour laquelle il existe Boost.IOStream existant pour aider à la mise en œuvre des flux. J'ai entendu des gens dire que les principaux problèmes avec le flux standard sont qu'ils n'étaient pas pensés avec le template/genericity car il n'y avait pas de fonctionnalité de template au moment où il a été implémenté. Ils suggèrent souvent que la conception d'une nouvelle bibliothèque de flux basée sur la générosité comme STL résoudrait beaucoup de problèmes de performance. – Klaim

+0

Les flux IO ont été réimplémentés pour la norme. L'un des problèmes que j'avais en 2002 en convertissant un système C++ pré-Standard en un système conforme aux normes était le changement de ce que certains d'entre eux étaient, lorsqu'ils sont devenus des classes et des fonctions modélisées. –

Répondre

3

Vous pourriez être intéressé par certaines des comparaisons de performance dans my question here. Même les fonctions de niveau le plus bas dans l'API de flux de bibliothèque standard C++ sont incroyablement lentes sous des implémentations courantes, et en regardant à travers le code source de par ex. Classe stringbuf Visual C++, je ne vois pas la copie de petits objets temporaires. Donc, les références rvalue ne sont pas susceptibles d'aider beaucoup. AFAICT, la raison principale de la lenteur des iostreams C++ est que les développeurs de bibliothèques sont bloqués avec l'idée que les E/S sont le goulot d'étranglement, donc il ne sert à rien de s'inquiéter des performances de la bibliothèque d'E/S. Mais I/O n'est décidément pas le goulot d'étranglement.

+0

Merci de nous avoir fait part de votre question, très complète! – Klaim

+0

Ouais. Les E/S sont le goulot d'étranglement ... mais le noyau du système d'exploitation le gère avec un tampon. La perte de temps dans les bibliothèques d'E/S n'est qu'une perte de temps. –

+0

@Zan: Cela m'a également surpris lorsque j'ai comparé pour la première fois les iostreams C++, mais ils sont si lents que même sur un cache de disque froid, les E/S ne sont pas le goulot d'étranglement. –