L'utilisation de -v (verbose) ralentit-elle les commandes?

Dans cette question: Comment supprimer tous les fichiers et sous-répertoires d'un répertoire SANS supprimer le répertoire dans bash? on demande comment supprimer tous les fichiers d'un dossier et non le dossier lui-même.

La réponse excellente de Matt inclut l'utilisation de l'indicateur -v dans la commande 'rm'.

rm -rfv dontDeleteMe && mkdir dontDeleteMe

La commande avec laquelle je suis parti était celle ci-dessus. Certainement utile, mais l'indicateur -v dans 'rm' et / ou en général ralentit les tâches effectuées via la ligne de commande?

J'ai un dossier avec des fichiers .txt (environ 100.000 d'entre eux) que j'ai créé, supprimé et recréé pour moi plusieurs fois. Quelques fois avec rm, d'autres fois dans le navigateur de fichiers, et j'ai l'impression qu'il est encore plus lent d'utiliser la commande rm comme indiqué ci-dessus. Le drapeau -v a-t-il quelque chose à voir avec cela?

command-line rm Eiriks
la source

Réponses:

Oui, l'indicateur -v ralentit la commande.

La plupart, sinon tous les logiciels (ou commandes) vérifieraient si un drapeau est fourni, puis exécuteraient une série de codes liés au drapeau. Dans le cas du drapeau -v, ils exécuteraient probablement un ensemble de commandes de sortie (comme echoou printf), qu’ils auraient plutôt sautées sans le drapeau.

Cela signifie plus de cycles d'instruction pour le processeur et donc plus de temps d'exécution.

Il est préférable que vous n'utilisiez pas l'option -v si vous n'allez pas lire / n'avez pas besoin des messages.

D'autre part, l'interface de ligne de commande serait / devrait être plus rapide que l'interface graphique, en supposant que vous n'incluez pas le temps nécessaire pour taper les commandes et en appuyant sur la Entertouche.

De ce blog de superutilisateur cette image explique très bien la lenteur

entrez la description de l'image ici

Pour la commande spécifique en question, les résultats de la commande time sont:

//with -v
real    0m8.753s
user    0m0.816s
sys     0m2.036s

//without -v
real    0m1.282s
user    0m0.124s
sys     0m1.092s

cela a été fait avec le répertoire contenant 100 000 fichiers vides

Utilisateur enregistré
la source

Je ne parlerais pas de "commandes d'écho". La plupart des programmes ne sont pas des scripts bash, ils n'appellent donc pas echo. Le problème est qu’ils écrivent sur stdout (ou stderr ), c’est-à-dire qu’ils effectuent des opérations d’E / S, qui nécessitent du temps (les E / S sont coûteuses), ainsi que des appels système (ce qui signifie davantage de changements de contexte et donc plus de cache miss etc.).

Bakuriu

Le principal problème de l’écriture sur stdout est le rendu réel de ce contenu; si vous redirigez stdout vers un fichier ou si les /dev/nullperformances ne sont pas aussi gênées que l'affichage de texte sur un émulateur de terminal.

Jacob Krall

Comme vous pouvez le constater sur le graphique, la différence de temps est négligeable si vous parlez de temps de réponse du point de vue de l'homme. Ainsi, si vous vous inquiétez de l'efficacité d'une personne surveillant la commande, ce n'est pas pertinent. Cela ne concerne que des quantités énormes de fichiers ou de nombreuses exécutions répétées où le temps passé sur l'ordinateur est précieux (par exemple, un serveur Web occupé ou un ancien ordinateur).

Paddy Landau

Le plus gros impact, et probablement le seul cas où cela aurait vraiment de l'importance, est lorsque vous exécutez la commande sur un ordinateur distant via SSH. Une journalisation détaillée peut facilement générer des dizaines de mégaoctets de trafic qui devraient être transmis de l'hôte à votre console. Une fois, j'ai constaté une accélération de l'ordre de 10 fois après la suppression de la journalisation excessive de la console d'un script que j'avais exécuté via SSH.

Sergey

Pourquoi ne pas découvrir vous-même: utilisez le temps.

$ time rm -rfv dontDeleteMe && mkdir dontDeleteMe
real    0m0.003s
user    0m0.001s
sys     0m0.002s

$ time rm -rf dontDeleteMe && mkdir dontDeleteMe
real    0m0.002s
user    0m0.001s
sys     0m0.001s

sethmuss
la source

Cela ne répond pas vraiment à la question. Une différence de 1 ms entre les exécutions uniques de chaque commande peut être causée par de nombreux facteurs. Également pas clair si vous avez omis la -vsortie ou le répertoire était vide.

Sans oublier que le ralentissement ne provient pas des instructions extra exécutées, mais du processus d’écriture dans un fichier ou le terminal. time' pretty much redirects the output to / dev / null '.

Cole Johnson