☰

Warum gibt es bei verschiedenen Umleitungsmethoden einen Unterschied in der Dauer der Befehlsausführung?

tag-icon • tag-icon io-redirection tty time
Warum gibt es bei verschiedenen Umleitungsmethoden einen Unterschied in der Dauer der Befehlsausführung?

Ich führe einen zeitgesteuerten findBefehl als normaler Benutzer aus.

Ich weiß, dass die Umleitung dazu dient, stdout/stderr-Meldungen auf dem Terminal zu verhindern. Wenn das der Fall ist, warum dauern dann unterschiedliche Umleitungsmethoden unterschiedlich lange? Hängt das irgendwie mit der Schreibgeschwindigkeit auf dem TTY zusammen oder gibt es einen anderen Grund dafür? Kann mir jemand dabei helfen, das zu verstehen?

$ id
uid=1000(user1) gid=1000(user1) groups=1000(user1),1001(user2)

$time find /
<truncated output>
real    0m13.902s
user    0m0.197s
sys 0m0.448s

$ time find /  >/dev/null  
<truncated output>
real    0m0.298s
user    0m0.068s
sys 0m0.206s

$time find /  2> /dev/null 
<truncated output>
real    0m13.279s
user    0m0.181s
sys 0m0.405s

$ time find /  > /dev/null 2>&1
real    0m0.306s
user    0m0.109s
sys 0m0.174s

Antwort1

Wenn Ihr Prozess ( find) die Ausgabe tatsächlich ausgeben muss, dauert das natürlich viel länger, als wenn Sie ihm sagen, dass die Ausgabe verworfen werden soll.

  • Wenn Sie verwenden find /, werden sowohl stdout als auch stderr an Ihr Terminal gesendet und es muss beide ausgeben (also die tatsächlichen Ergebnisse und alle Berechtigungsfehler usw.).

  • Wenn Sie verwenden, time find / >/dev/nulllöschen Sie die Standardausgabe des Befehls, drucken aber trotzdem alle Fehler aus (falls vorhanden). Ihren Ergebnissen nach zu urteilen, haben Sie viele gültige Ergebnisse und sehr wenige Fehler.

  • Wenn Sie verwenden time find / 2> /dev/null, wird die Standardausgabe des Befehls weiterhin an Ihr Terminal gesendet, aber jetzt löschen Sie einfach den stderr. Wenn Sie über ein Dateisystem herausfinden würden, für dessen Lesen Sie keine Berechtigung haben, wäre dies eigentlich ziemlich schnell.

  • Wenn Sie verwenden time find / > /dev/null 2>&1, löschen Sie die Standardausgabe und senden dann den Standardfehler dorthin, wohin die Standardausgabe gesendet wird, d. h. Sie löschen beides. Dies gibt nichts aus und ist daher der schnellste aller Befehle.

Antwort2

Ich weiß, dass die Umleitung dazu dient, stdout/stderr-Meldungen auf dem Terminal zu verhindern.

Nein, Sie können auch zu einer Datei weiterleiten:

find / > ~/all-the-files

Hat es irgendwie etwas mit der Schreibgeschwindigkeit auf dem TTY zu tun?

Mit einem Wort: Ja.

Unabhängig davon, welche Art von Terminal Sie verwenden (virtuelle Konsole in Linux, ein lokales xterm, etwas über eine SSH-Verbindung), muss der eigentliche Terminalemulator alles zeichnen, was auf dem Terminal gedruckt wird, auch wenn es in diesem Fall bald herausgescrollt wird. (Eine Verbindung über moshkönnte hier eine Ausnahme sein.)

Bei einer Netzwerkverbindung muss auch die Übertragungsverzögerung berücksichtigt werden. Einige Daten werden möglicherweise gepuffert, wenn es viele sind, nicht alle. Wenn Sie etwas zu umleiten /dev/null, wird es nirgendwo gespeichert und auch nicht gezeichnet. Die Umleitung zu einer Datei ist bei mäßigen Datenmengen ebenfalls schnell, da das Betriebssystem die Schreibvorgänge wahrscheinlich im Speicher zwischenspeichert und erst danach tatsächlich verzögert auf die Festplatte schreibt. Bei großen Datenmengen kann das Schreiben auf die Festplatte auch zum Engpass werden. (oder, wenn Sie es geschafft haben, dass der Prozess die Ausgabe im synchronen E/A-Modus schreibt)

Bei Programmen mit großen Ausgabemengen würde allein das Formatieren der Ausgabe ( printf()innerhalb des Prozesses) und der Aufruf an das Betriebssystem zum Schreiben der Ausgabe Zeit in Anspruch nehmen, selbst wenn die Daten an umgeleitet würden /dev/null. In einem solchen Fall könnte es sogar noch schneller gehen, wenn Sie das Programm dazu bringen könnten, die Ausgabe vollständig zu unterdrücken. Dies ist bei wahrscheinlich nicht der Fall find, ich würde annehmen, dass es an der E/A-Geschwindigkeit oder dem Systemaufruf-Overhead liegt.

Beachten Sie auch, dass beim wiederholten Ausführen findim selben Verzeichnisbaum das erste Mal wahrscheinlich langsamer ist als die anderen Male, da beim ersten Mal möglicherweise von der Festplatte gelesen werden muss, während danach viele Daten vom Betriebssystem zwischengespeichert werden.

verwandte Informationen