Czy użycie -v (pełne) spowalnia polecenia?

W tym pytaniu: Jak usunąć wszystkie pliki i podkatalogi w katalogu BEZ usunięcia katalogu w bash? pytane jest, jak usunąć cały plik w folderze, a nie sam folder.

Doskonała odpowiedź Matta obejmuje użycie flagi -v w poleceniu „rm”.

rm -rfv dontDeleteMe && mkdir dontDeleteMe

Polecenie, które mi pozostało, było tym powyżej. Z pewnością przydatne, ale czy flaga -v w 'rm' i / lub ogólnie spowalnia zadania wykonywane za pomocą wiersza poleceń?

Mam folder z plikami .txt (około 100 000), który kilka razy utworzyłem, usunąłem i odtworzyłem dla siebie. Czasami z rm, czasem w przeglądarce plików i mam wrażenie, że jeszcze wolniej jest używać polecenia rm jak pokazano powyżej. Czy flaga -v ma z tym coś wspólnego?

command-line rm

— Eiriks
źródło

Odpowiedzi:

Tak, flaga -v spowalnia polecenie.

Większość, jeśli nie wszystkie programy (lub polecenia), sprawdzałyby, czy dostarczona jest flaga, a następnie wykonywało wiązkę kodu związanego z flagą. W przypadku flagi -v prawdopodobnie wykonaliby kilka poleceń wyjściowych (takich jak echolub printf), które woleliby pominąć bez flagi.

Oznacza to więcej cykli instrukcji dla procesora, a tym samym dłuższy czas wykonania.

Lepiej jest, jeśli nie użyjesz opcji -v, jeśli nie zamierzasz czytać / potrzebować wiadomości.

Z drugiej strony CLI będzie / powinien być szybszy niż GUI, zakładając, że nie uwzględnisz czasu potrzebnego na wpisanie poleceń i naciśnięcie Enterklawisza.

Z tego bloga superużytkownika ten obraz bardzo dobrze wyjaśnia powolność

wprowadź opis zdjęcia tutaj

Dla określonego polecenia, wyniki polecenia czasu są

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

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

zrobiono to z katalogiem zawierającym 100000 pustych plików

— zarejestrowany użytkownik
źródło

Nie mówiłbym o „poleceniach echa”. Większość programów nie jest skryptami bash, więc nie wywołują echa. Problem polega na tym, że piszą na stdout (lub stderr ), innymi słowy, wykonują operacje we / wy, które wymagają czasu (we / wy jest kosztowne), a także wymagają wywołań systemowych (co oznacza więcej przełączeń kontekstu, a tym samym więcej pamięci podręcznej itp.).

— Bakuriu

Głównym problemem związanym z pisaniem na standardowe wyjście jest faktyczne renderowanie tej zawartości; jeśli przekierujesz standardowe wyjście do pliku lub /dev/nullwydajność nie jest tak bardzo ograniczona, jak wyświetlanie tekstu na emulatorze terminali.

— Jacob Krall

Jak widać z wykresu, różnica czasu jest znikoma, jeśli mówimy o czasie reakcji z punktu widzenia człowieka. Dlatego jeśli martwisz się wydajnością osoby obserwującej polecenie, nie ma to znaczenia. Ma to zastosowanie tylko w przypadku ogromnej liczby plików lub wielu powtarzanych uruchomień, w których cenny jest czas komputera (np. Zajęty serwer internetowy lub starożytny komputer).

— Paddy Landau

Największy wpływ i prawdopodobnie jedyny przypadek, w którym miałoby to naprawdę znaczenie, to uruchomienie polecenia na zdalnym komputerze za pośrednictwem SSH. Pełne rejestrowanie może z łatwością wygenerować dziesiątki megabajtów ruchu, który musiałby zostać przesłany z hosta do konsoli. Kiedyś doświadczyłem przyspieszenia rzędu 10x po usunięciu nadmiernego logowania do konsoli ze skryptu, który uruchomiłem przez SSH.

— Sergey

Dlaczego nie dowiesz się sam: wykorzystaj czas.

$ 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
źródło

To tak naprawdę nie odpowiada na pytanie. Różnica 1 ms między pojedynczymi uruchomieniami każdego polecenia może być spowodowana wieloma czynnikami. Nie jest również jasne, jeśli pominięto dane -vwyjściowe lub katalog był pusty.

Nie wspominając o spowolnieniu nie wynika z dodatkowych wykonanych instrukcji, ale z procesu zapisywania go do pliku lub terminala. time' pretty much redirects the output to / dev / null '.

— Cole Johnson