Exécuter des commandes verbalement les ralentit-il?

37

Je me suis retrouvé à utiliser le -vdrapeau pour de nombreuses applications de moins en moins (en particulier pour des choses triviales comme taret cp). Cependant, lorsque je décompressais un fichier volumineux, cela prendrait plus de temps que lorsque je n’utilisais pas le -vdrapeau.

Je suppose que cela est dû au fait que le terminal doit traiter le texte et que je remplis le tampon dont il dispose. Mais ma question est la suivante: l’application est-elle réellement ralentie ou s’achève-t-elle dans le même laps de temps et ce que je constate est que le terminal tente de rattraper son retard?

linux unix shell

— n0pe
source

Avez-vous essayé de chronométrer, par exemple, tar xvf file.tar > /dev/nullcontre tar xf file.tar? La redirection vers /dev/nulldevrait sortir votre terminal de cela.

— Benjamin Bannier

3

En outre, notez que stdoutet stderrsont mis en tampon de ligne - ce qui signifie que le remplissage des tampons ne prend pas si longtemps - ce sont les printfappels bloquants (et par la sortie du terminal d'extension) qui durent éternellement.

— new123456

1

Si vous aviez parlé des commandes Windows, je dirais sûrement que c'est vrai :)

— kokbira

Pour les tâches intensives en processeur, en fonction du nombre d'E / S que vous effectuez, vous risquez de constater une dégradation des performances.

— utilisateur

31

Oui, exécuter verbose ralentira vos applications.

Combien dépend de l'application.

Chaque impression sur le terminal nécessitera un temps de traitement supplémentaire. Dans le cas où vous utilisez printf () ou l’une de ses sœurs, cela représente une perte de temps considérable en termes de traitement.

En outre, le terminal doit traiter ces données. Il existe une quantité limitée d’espace tampon entre l’application et le terminal, et le canal IO se bloque jusqu’à ce qu’il y ait suffisamment d’espace dans ledit tampon pour sortir les données. L’application ne pourra généralement pas continuer tant que ce blocage est en cours. ¹

En outre, le fait d'afficher le texte de débogage sur le terminal consommera des cycles de traitement. Là encore, 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 timeprogramme peut être utilisé pour déterminer avec assez de précision le temps d’exécution d’une commande. Exécuter le même programme deux fois dans le temps, une fois avec le débogage et une fois sans, vous montrera toute la différence que cela fait. 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 exécutions de test 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 lors de la première exécution ...

¹ Dans le cas d'une application multithread, seul le thread qui exécute la sortie de débogage sera réellement bloqué.

— Majenko
source

La plupart des programmeurs apprennent très vite (Borland C sous DOS);)

— Dragos

Bien sûr, si la fenêtre de la console est masquée (ou même partiellement couverte), cela n'aura pas autant d'impact que lorsque la console sera visible. Ouvrez une invite de commande et faites un dir c:\/s/a. Vous pouvez voir le changement de vitesse quand il est complètement visible et partiellement couvert. Vous ne pouvez pas voir s’accélérer lorsque minimisé, mais c’est nettement plus rapide, bien que vous deviez redémarrer si vous souhaitez tester, afin de contourner la mise en cache, ce qui le ferait de toute façon plus rapidement, car cela n’aurait pas été possible. accéder au disque.

— Synetech

1

@Syn Nous parlons de Linux ici.

— Majenko

1

@ Matt c'est toujours un commentaire valide. S'il vous plaît soyez respectueux.

— nhinkle

@ Matt, doh! Je n'ai pas remarqué. (Peut-être que j'ai été distrait du commentaire DOS.) Quoi qu'il en soit, Linux est assez différent, mais je me demande s'il en va de même (consoles visibles avec beaucoup de texte défilant plus lentement).

— Synetech

8

Cela dépend de l'application que vous utilisez. Cependant, en règle générale, nous pouvons dire que verbose ralentira les applications Linux les plus courantes car elles doivent synchroniser leurs actions entre stdout et les limites d'E / S ou de processeur.

— Diogo
source

6

En utilisant yescomme scénario de test sur OS X 10.7, il semble que le fait d’imprimer de nombreuses sorties sur le terminal, comme on pouvait s’y attendre, semble vraiment important.

Pour quantifier cela un peu plus loin, j'ai couru yespendant 5 secondes, dans un cas, imprimant la sortie sur le terminal et l'enregistrant dans un fichier (avec tee), dans l'autre cas, procédant de même, sauf en redirigeant stdoutvers /dev/null:

yes | tee yeslog_term & sleep 5 && killall yes && wc -l yeslog_term
yes | tee yeslog_noterm > /dev/null & sleep 5 && killall yes && wc -l yeslog_noterm

Le cas 1. donne 2371584 lignes et le cas 2. donne 136421376 lignes, soit 57 fois plus. La «performance» de yes(mesurée par le nombre de lignes imprimées par unité de temps) est dans ce cas donc 57 fois plus lente .

Une note de côté ici est que j'ai utilisé yesen conjonction avec teeici, ce qui pourrait influencer légèrement les résultats, mais je pense que les résultats sont toujours valables.

Une autre indication du ralentissement du programme est que, yeslorsqu’il exécute la sortie sur un terminal, celui-ci utilise environ 100% de la CPU et yesseulement environ 37%, tandis qu’il exécute yessans générer de sortie vers un terminal machine principale, donc yespourrait utiliser plus de CPU si elle était capable, sauf qu'il a été ralenti par le terminal).

— Tim
source

5

Il est facile de répondre que oui, cela ralentira l'application. Mais une réponse beaucoup plus vraie est que cela n’a aucune importance dans 99% des cas.

Si votre application effectue tout type de travail nécessitant un peu de puissance du processeur, les chances d’imprimer quelques lignes de texte supplémentaires sur l’écran, ce qui fait toute différence, est proche de 0%.

En fait, vous pouvez facilement faire votre propre jugement: si l'application crache un immense mur de texte, cela pourrait vous coûter un petit peu. Peut être.

— slarpspark
source

3

-1 ce n'est tout simplement pas vrai. printf()est incroyablement cher

— Thomas Bonini

1

Ce que j'ai dit était vrai. Ce que vous essayez de faire ressembler à ce que j'ai dit, cependant, est tout autre chose. Je ne dis rien sur l'efficacité d'une impression stdlib spécifique. Je dis que les programmes devraient faire assez de travail pour que le temps passé à l’impression soit négligeable. Maintenant, va troll quelqu'un d'autre.

— slarpspark

@slarpspark: ce n'est pas nécessairement négligeable, même si nous retirons printf () de l'équation, le flux d'octets doit toujours passer par bash, puis l'émulateur de terminal, puis l'émulateur de terminal doit restituer le texte à l'écran Après avoir analysé les caractères d'échappement, le rendu du texte n'est pas bon marché s'il est effectué à la vitesse d'une commande verbeuse. et il serait particulièrement coûteux si le programme vide le tampon de sortie à chaque ligne car cela implique des changements de contexte. Lors de l’écriture de scripts python, j’ai souvent constaté que le fait de supprimer des impressions en boucle serrée peut parfois amener de 10 à 1.

— Lie Ryan

Qu'en est-il d'une commande s'exécutant sur SSH, alors même si le temps de calcul est minime, une fois que vous avez introduit la latence du réseau, cela est sûrement important?

— ec2011

3

Un code commenté est généralement évalué avec une instruction if et chaque fois qu'il passe le contrôle à une fonction d'affichage, plus le temps pris est long, plus le contexte peut être changé, plus il y a d'interruptions.

Mais cela dépend, si votre code prolixe est un fil séparé qui ne fait que vérifier l’état d’achèvement, la différence est négligeable.

Cette question peut grandement bénéficier de la contribution des programmeurs expérimentés de stackoverflow. Je suggère de déménager :)

— Dragos
source