Oui, l'exécution de verbose ralentira vos applications.
Combien dépend de l'application.
Chaque impression vers le terminal nécessitera un temps de traitement supplémentaire. Dans le cas de l'utilisation de printf() ou de l'une de ses sœurs, il s'agit d'une perte de traitement assez importante.
De plus, le terminal doit traiter ces données. Il y a une quantité limitée d'espace tampon entre l'application et le terminal, et le canal IO se bloquera jusqu'à ce qu'il y ait suffisamment d'espace dans ledit tampon pour réellement sortir les données. L'application ne pourra généralement pas continuer tant que ce blocage aura lieu.
De plus, le fait d'afficher le texte de débogage sur le terminal consommera des cycles de traitement. Encore une fois, cela dépend à la fois de l'application (la quantité de débogage), du programme du terminal (polices utilisées, effets, etc.) et même du pilote X Windows utilisé (accélération matérielle, etc.).
Le time programme peut être utilisé pour déterminer assez précisément la durée d'exécution d'une commande. Exécuter le même programme deux fois dans le temps, une fois avec débogage et une fois sans, vous montrera à quel point cela fait une différence. Je suggérerais d'exécuter la commande une fois avant d'effectuer les tests pour s'assurer que la mise en cache est la même pour les deux tests de la commande. Vous ne voulez pas fausser les résultats en faisant en sorte que la deuxième exécution soit beaucoup plus rapide, car la plupart des données ont été mises en cache par la première exécution maintenant, n'est-ce pas...
Dans le cas d'une application multithread, seul le thread effectuant la sortie de débogage sera réellement bloqué.
Cela dépend de l'application que vous exécutez. Cependant, en général, nous pouvons dire que verbose ralentira la plupart des applications Linux courantes car elles doivent synchroniser leurs actions entre stdout et I/O ou les limites du processeur.
Utilisation de yes en tant que cas de test sur OS X 10.7, il semble en effet important si vous imprimez beaucoup de sortie sur le terminal, comme on pourrait s'y attendre.
En quantifiant un peu plus loin, j'ai couru yes pendant 5 secondes, dans un cas en imprimant la sortie sur le terminal et en l'enregistrant dans un fichier (avec tee ), dans l'autre cas en faisant la même chose sauf en redirigeant stdout à /dev/null :
yes | tee yeslog_term & sleep 5 && killall yes && wc -l yeslog_termyes | tee yeslog_noterm > /dev/null & sleep 5 && killall yes && wc -l yeslog_noterm
Cas 1. donne 2371584 lignes et cas 2. donne 136421376 lignes, soit 57 fois plus. Les 'performances' de yes (tel que mesuré par le nombre de lignes qu'il imprime par unité de temps) est dans ce cas donc 57 fois plus lent .
Une remarque ici est que j'ai utilisé yes en conjonction avec tee ici, ce qui pourrait influencer légèrement les résultats, mais je pense que les résultats sont toujours valables.
Une autre indication que le programme est ralenti est que l'exécution de yes lors de la sortie vers un terminal, le terminal utilise environ 100 % de CPU et yes seulement environ 37 %, tout en exécutant yes sans sortir sur un terminal, il utilise la totalité des 100 % (c'est sur une machine multicœur, donc yes pourrait utiliser plus de processeur s'il le pouvait, sauf qu'il était ralenti par le terminal).