I comandi in esecuzione li rendono verbalmente più lenti?

37

Mi sono ritrovato a usare la -vbandiera per molte applicazioni sempre meno (specialmente per cose banali come tare cp). Tuttavia, quando l'ho fatto e stavo, per esempio, decomprimendo un file di grandi dimensioni, ci vorrebbe più tempo rispetto a quando non ho usato la -vbandiera.

Suppongo che ciò avvenga perché il terminale deve elaborare il testo e sto riempiendo tutto il buffer che potrebbe avere. Ma la mia domanda è: questo rende l'applicazione effettivamente più lenta o si completa nello stesso lasso di tempo e quello che vedo è il terminale che sta cercando di recuperare?

linux unix shell

— n0pe
fonte

Hai provato a tempo ad esempio tar xvf file.tar > /dev/nullcontro tar xf file.tar? Il reindirizzamento a /dev/nulldovrebbe togliere il tuo terminale da questo.

— Benjamin Bannier,

3

Inoltre, si noti che stdoute stderrsono line-buffered - significa che riempire i buffer non ci vuole molto tempo - è il blocco printfchiamate (e terminale di uscita estensione) che prende sempre.

— nuovo123456,

1

Se avessi parlato dei comandi di Windows, direi sicuramente che è vero :)

— kokbira,

Per l'attività intensiva della CPU, a seconda di quanto IO stai facendo, potresti notare un orribile degrado delle prestazioni.

— utente

31

Sì, eseguire verbose rallenterà le tue applicazioni.

Quanto dipende dall'applicazione.

Ogni stampa sul terminale richiederà tempi di elaborazione aggiuntivi. Nel caso dell'uso di printf () o di una delle sue sorelle, si tratta di una notevole quantità di elaborazione sprecata.

Inoltre, il terminale deve gestire tali dati. Esiste una quantità limitata di spazio buffer tra l'applicazione e il terminale e il canale IO si bloccherà fino a quando non vi sarà spazio sufficiente in detto buffer per produrre effettivamente i dati. In genere l'applicazione non sarà in grado di continuare mentre si sta verificando questo blocco. ¹

Inoltre, l'atto di visualizzare il testo di debug sul terminale richiederà cicli di elaborazione. Ancora una volta, questo dipende sia dall'applicazione (la quantità di debug), dal programma terminale (caratteri usati, effetti, ecc.) E persino dal driver X windows in uso (accelerazione hardware, ecc.).

Il timeprogramma può essere utilizzato per determinare in modo abbastanza accurato il tempo necessario per l'esecuzione di un comando. Eseguire lo stesso programma due volte nel tempo, una volta con il debug e una volta senza, ti mostrerà quanta differenza fa. Suggerirei di eseguire il comando una volta prima di eseguire i test per garantire che la memorizzazione nella cache sia la stessa per entrambe le esecuzioni di test del comando. Non si desidera distorcere i risultati facendo sì che la seconda esecuzione vada molto più veloce perché la maggior parte dei dati è stata memorizzata nella cache dalla prima esecuzione ora si ...

¹ Nel caso di un'applicazione multithread, verrà bloccato solo il thread che esegue l'output di debug.

— Majenko
fonte

La maggior parte dei programmatori lo impara abbastanza velocemente (Borland C in DOS);)

— Dragos

Ovviamente se la finestra della console è nascosta (o anche parzialmente coperta), non avrà alcun impatto quasi quanto quando la console è visibile. Aprire un prompt dei comandi ed eseguire un dir c:\/s/a. Puoi vedere la variazione di velocità quando è completamente visibile e parzialmente coperta. Non puoi vederlo accelerare quando ridotto a icona, ma è sicuramente più veloce, anche se dovresti riavviare se vuoi testare, al fine di bypassare la memorizzazione nella cache che lo renderebbe comunque più veloce, dal momento che non avrebbe per accedere al disco.

— Synetech,

1

@Syn Stiamo parlando di Linux qui.

— Majenko,

1

@Matt è ancora un commento valido. Per favore sii rispettoso.

— Pensa

@ Matt, doh! Non me ne sono accorto (Forse mi sono distratto dal commento su DOS.) Comunque, Linux è abbastanza diverso, ma mi chiedo se lo stesso valga per esso (console visibili con un sacco di scorrimento del testo che scorre più lentamente).

— Synetech,

8

Dipende dall'applicazione in esecuzione. Tuttavia, in generale, possiamo dire che verbose rallenterà le applicazioni Linux più comuni poiché devono sincronizzare le loro azioni tra stdout e I / O o limiti del processore.

— Diogo
fonte

6

Usando yescome test case su OS X 10.7, sembra davvero importante se si stampa molto output sul terminale, come ci si aspetterebbe.

Quantificando ulteriormente questo, ho eseguito yesper 5 secondi, in un caso stampando l'output sul terminale e salvandolo su un file (con tee), nell'altro caso facendo lo stesso tranne reindirizzare stdouta /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

Il caso 1. fornisce 2371584 linee e il caso 2. dà 136421376 linee, o 57 volte di più. La "prestazione" di yes(misurata dalla quantità di linee che stampa per unità di tempo) è in questo caso quindi 57 volte più lenta .

Una nota a margine qui è che ho usato yesinsieme a teequi, il che potrebbe influenzare leggermente i risultati, tuttavia penso che i risultati siano ancora validi.

Un'altra indicazione del rallentamento del programma è che yesdurante l' esecuzione in uscita su un terminale, il terminale utilizza circa il 100% della CPU e yessolo circa il 37%, mentre in esecuzione yessenza uscita su un terminale utilizza l'intero 100% (Questo è su un multi- macchina di base, quindi yespotrebbe usare più CPU se fosse in grado, tranne che fosse rallentato dal terminale).

— Tim
fonte

5

È facile rispondere semplicemente sì, rallenterà l'applicazione. Ma una risposta molto più vera è che non importa nel 99% dei casi.

Se l'applicazione sta eseguendo qualsiasi tipo di lavoro che richiede effettivamente un po 'di potenza della CPU, le possibilità di stampare alcune righe di testo aggiuntive sullo schermo facendo qualsiasi tipo di differenza è vicina allo 0%.

In effetti, puoi facilmente esprimere il tuo giudizio: se l'applicazione sta vomitando un immenso muro di testo, potrebbe effettivamente costarti un po '. Può essere.

— slarpspark
fonte

3

-1 questo non è vero. printf()è follemente costoso

— Thomas Bonini,

1

Quello che ho detto era vero. Quello che stai cercando di far sembrare che ho detto, tuttavia, è qualcos'altro. Non sto dicendo nulla sull'efficienza di una specifica stampa stdlib. Sto dicendo che i programmi dovrebbero fare abbastanza lavoro che il tempo impiegato per la stampa è trascurabile. Ora vai a troll qualcun altro.

— slarpspark,

@slarpspark: non è necessariamente trascurabile, anche se prendiamo printf () dall'equazione, il flusso di byte deve ancora passare attraverso bash, quindi l'emulatore di terminale, quindi l'emulatore di terminale deve rendere il testo sullo schermo dopo aver analizzato i caratteri di escape e il rendering del testo non è economico se eseguito alla velocità che alcuni comandi dettagliati potrebbero fare; e sarebbe particolarmente costoso se il programma svuota il buffer di output su ogni riga in quanto ciò significa cambi di contesto. Durante la scrittura di script Python ho spesso esperienza che a volte la rimozione di stampe in loop stretto può portare da 10 a 1 secondi.

— Lie Ryan,

Che dire di un comando in esecuzione su SSH, quindi anche se il tempo di CPU è minimo, una volta introdotta la latenza di rete sicuramente questo è significativo?

— ec2011,

3

Un codice dettagliato viene di solito valutato con un'istruzione if e ogni volta che passa il controllo a una funzione di visualizzazione più tempo impiega, il contesto può essere cambiato, più interruzioni.

Ma dipende, se il codice dettagliato è un thread separato che controlla di tanto in tanto lo stato di completamento, la differenza è trascurabile.

Questa domanda può beneficiare molto del contributo dei programmatori esperti di StackOverflow. Suggerisco di spostarmi :)

— Dragos
fonte