Poniższy przykład mnie zaskoczył. Wydaje się to sprzeczne z intuicją ... poza tym, że jest więcej czasu na echo | sed
kombo dla użytkownika.
Dlaczego echo
zużywa tyle czasu sys, gdy działa sam, a może powinno być pytanie, jak sed
zmienia się stan gry? Wydaje się, że echo
byłoby potrzeby, aby zrobić to samo echo-ing w obu przypadkach ...
time echo -n a\ {1..1000000}\ c$'\n' >file
# real 0m9.481s
# user 0m5.304s
# sys 0m4.172s
time echo -n a\ {1..1000000}\ c$'\n' |sed s/^\ // >file
# real 0m5.955s
# user 0m5.488s
# sys 0m1.580s
time echo ... |cat >file
a nawettime echo ... |perl -ne 'print'
są podobne czasy dosed
wersji.Odpowiedzi:
bahamat i Alan Curry mają rację: wynika to ze sposobu, w jaki twoja powłoka buforuje wyjście
echo
. W szczególności twoja powłoka jest bash i wydaje jednowrite
wywołanie systemowe na linię. Stąd pierwszy fragment powoduje, że 1000000 zapisuje do pliku dyskowego, podczas gdy drugi fragment powoduje, że 1000000 zapisuje do potoku, a sed (w dużej mierze równolegle, jeśli masz wiele procesorów), robi znacznie mniejszą liczbę zapisów do pliku dyskowego ze względu na jego wynik buforowanieMożesz obserwować, co się dzieje, biegając strace .
Inne powłoki, takie jak ksh buforują dane wyjściowe
echo
nawet wtedy, gdy są wielowierszowe, więc nie zobaczysz żadnej różnicy.Dzięki bash mam podobne stosunki czasowe. Z ksh widzę, że drugi fragment działa wolniej.
źródło
ksh
przykład jest bardziej