L'uso di -v (verbose) rallenta i comandi?


34

In questa domanda: come rimuovere tutti i file e le sottodirectory in una directory SENZA cancellare la directory in bash? viene chiesto come eliminare tutti i file in una cartella e non la cartella stessa.

La risposta eccellente di Matt include l'uso del flag -v al comando 'rm'.

rm -rfv dontDeleteMe && mkdir dontDeleteMe

Il comando che ho lasciato era quello sopra. Certamente utile, ma il flag -v in 'rm' e / o in generale rallenta le attività eseguite dalla riga di comando?

Ho una cartella con file .txt (circa 100.000) che ho creato, cancellato e ricreato da solo alcune volte. Alcune volte con rm, altre volte nel filebrowser, e ho la sensazione che sia ancora più lento usare il comando rm come mostrato sopra. Il flag -v ha qualcosa a che fare con questo?

Risposte:


37

Sì, il flag -v rallenta il comando.

La maggior parte, se non tutti i software (o comandi) verificherebbe se viene fornito un flag, quindi eseguirà un gruppo di codice relativo al flag. Nel caso del flag -v, probabilmente eseguiranno un gruppo di comandi di output (come echoo printf), che preferirebbero saltare senza il flag.

Ciò significa più cicli di istruzione per il processore e quindi più tempo di esecuzione.

È meglio se non usi -v flag se non hai intenzione di leggere / hai bisogno dei messaggi.

D'altra parte, la CLI dovrebbe / dovrebbe essere più veloce della GUI, supponendo che non si includa il tempo necessario per digitare i comandi e premere il Entertasto.

Da questo blog di superutente questa immagine spiega molto bene la lentezza

inserisci qui la descrizione dell'immagine

Per il comando specifico in questione, i risultati del comando time sono

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

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

questo è stato fatto con la directory contenente 100000 file vuoti


9
Non parlerei di "comandi echo". La maggior parte dei programmi non sono script bash, quindi non chiamano eco. Il problema è che stanno scrivendo su stdout (o stderr ), in altre parole, stanno eseguendo operazioni di I / O, che richiedono tempo (I / O è costoso) e richiedono anche chiamate di sistema (il che significa più switch di contesto e quindi più cache miss ecc.).
Bakuriu,

23
Il problema principale con la scrittura su stdout è il rendering effettivo di quel contenuto; se si reindirizza stdout su un file o /dev/null, le prestazioni non sono così ostacolate come la visualizzazione di testo su un emulatore di terminale.
Jacob Krall,

Come puoi vedere dal grafico, la differenza nel tempo è trascurabile se parli del tempo di risposta dal punto di vista umano. Pertanto, se sei preoccupato per l'efficienza di una persona che osserva il comando, non è rilevante. È rilevante solo per un numero enorme di file o per molte esecuzioni ripetute in cui il tempo del computer è prezioso (ad esempio un server Web occupato o un computer antico).
Paddy Landau,

L'impatto maggiore, e probabilmente l'unico caso in cui sarebbe davvero importante, è quando si esegue il comando su una macchina remota tramite SSH. La registrazione dettagliata può facilmente generare decine di megabyte di traffico che dovrebbero essere trasmessi dall'host alla tua console. Una volta ho sperimentato uno speedup dell'ordine di 10x dopo aver rimosso la registrazione eccessiva della console da uno script che ho eseguito tramite SSH.
Sergey,

5

Perché non scoprirti: usa il tempo.

$ 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

10
Questo non risponde davvero alla domanda. Una differenza di 1 ms tra le singole esecuzioni di ciascun comando potrebbe essere causata da molti fattori. Inoltre, non è chiaro se si è omesso l' -voutput o la directory era vuota.

Per non parlare del rallentamento non deriva dalle istruzioni extra eseguite, ma dal processo di scrittura su un file o sul terminale. time' pretty much redirects the output to / dev / null'.
Cole Johnson,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.