J'essayais de résoudre un problème sur l'interviewstreet. Après quelque temps, je détermine que je passais en réalité le gros de mon temps à lire l'entrée. Cette question particulière a eu beaucoup d'informations, de sorte que cela a du sens. Ce qui n'a pas de sens, c'est pourquoi les méthodes d'entrée variables ont eu de telles représentations différentes:
Au départ, j'avais: p> le remplaçant le rendit notable plus rapide: p > réécrit tout pour utiliser Scanf l'a rendu encore plus rapide p> char command;
scanf("get_%c", &command);
4 Réponses :
Il y a une grande variation de ces routines car la vitesse d'entrée de la console ne compte presque jamais.
et où il est (UNIX Shell), le code est écrit en C, se lit directement à partir du périphérique STDIN et est efficace.
Ce que je trouve particulièrement drôle, c'est comment j'ai lu dans l'un des livres C ++ (était-il c ++ Bible?) Comment iOSTREAM en théorie peut être plus rapide que les fonctions STDIO car il utilise des fonctions virtuelles au lieu d'analyser le texte comme "% S% S% D% D ", mais que dans la pratique, il est 10x-20x plus lent. Je me classe là avec la possibilité théorique de Java étant effectivement plus rapide que c parce que la machine virtuelle peut profiler le code à la volée.
@satuon: personnellement, je trouve iostream horrible. Les différents niveaux d'indirections et de l'interface non intuitive ne font que malheureusement. Le problème de iostream est que sa tenue et remonte à l'âge précoce de C ++, où des modèles et des exceptions étaient toujours sous enquêtes. Vous avez donc une sorte de solution à moitié cuite congelée pour des raisons de «compatibilité ascendante». soupir .
Donc, fondamentalement, iostream est mal mis en œuvre car personne ne l'utilise pour High Performance Io?
@WinstoneWert - Il est probablement optimisé pour la flexibilité et l'élégance de la conception. Bien que dans la pratique, il ne soit probablement pas opté pour rien puisque personne ne l'utilise!
au risque d'être évité, des flux d'E / S sont, en général, plus lents et plus volumineux que leurs homologues C. Ce n'est pas une raison d'éviter d'utiliser de nombreuses fins, car ils sont plus sûrs (jamais dans un bogue Scanf ou Printf? Pas très agréable) et plus général (Ex: opérateur d'insertion surchargé vous permettant de produire des types définis par l'utilisateur). Mais je dirais aussi que ce n'est pas une raison de les utiliser dogmatiquement dans un code très critique de la performance.
Je trouve les résultats un peu surprenant cependant. Sur les trois que vous avez énuméré, j'aurais soupçonné que cela soit le plus rapide: p> raison: pas d'allocations de mémoire nécessaires et une lecture simple d'un tampon de caractère. C'est également vrai de votre exemple C ci-dessous, mais appelez Scanf pour lire un seul caractère à plusieurs reprises, n'est nulle part à l'optimal, que ce soit au niveau conceptuel, car Scanf doit analyser la chaîne de format que vous avez transmise à chaque fois. Je serais intéressé par les détails de votre code d'E / S, car il semble qu'il existe une possibilité raisonnable de quelque chose de mal tournant lorsque Scanf appelle à lire un seul personnage s'avère être le plus rapide. Je dois juste demander et sans vouloir offenser, mais le code est vraiment compilé et relié à des optimisations sur? P> maintenant sur votre premier exemple: P> std::string command;
std::cin >> command;
GProf est bon (mais pas génial) pour identifier les goulots d'étranglement dans les processus liés à la CPU. C'est mauvais (vraiment vraiment mauvais!) Pour identifier des goulots d'étranglement dans les processus liés à des I / O.
@David: Les auteurs de GProf a écrit un papier à ce sujet, mais bien sûr, qui lit ces choses? Tout le monde pense que c'est un outil de recherche de goulots d'étranglement, mais ils ne font aucune revendication de ce type.
Les routines STDIO ont beaucoup d'optimisation dans leur historique et leur optimisation des performances auxiliaires tels que SetVBuf () . Même si conceptuellement scanf () semble complexe, examinez toute mise en œuvre: ce code d'analyse de chaîne est très rapide.
@Wallyk: True, mais même avec l'analyse des chaînes la plus rapide, elle est faite par caractère dans son exemple! C'est une grande surprise que Char buf [n]; Cin.Lead (BUF, N); serait tellement plus lent (réellement surprenant que ce n'est pas plus rapide, mais iostreams sont une partie très volumineuse et ancienne de C ++).
GPROF Seuls des échantillons pendant le temps de la CPU, pas pendant le temps bloqué. Donc, un programme peut passer une heure à faire des E / S et un calculateur de microseconde, et GPROF Voir seulement le microsecond .
Pour une raison quelconque, ce n'est pas bien connu.
Par défaut, les iOSTreams standard sont configurés pour travailler ensemble et avec la bibliothèque C Stdio - en pratique, cela signifie utiliser Pour obtenir de bonnes performances en utilisant Voir la question Stackoverflow suivante pour plus de détails.
CIN et COUT pour des choses autres que les entrées interactives et la production a tendance à être lente.
CIN et COUT , vous devez désactiver la synchronisation avec stdio. Pour une entrée haute performance, vous pouvez même vouloir détacher les flux.