Różnica w wydajności między argumentem stdin a wierszem poleceń

W przypadku niektórych poleceń można podać określone dane wejściowe jako argument stdin lub wiersz poleceń.

W szczególności załóżmy, że commandmożemy przyjąć wejście standardowe i nazwę pliku jako argument wiersza poleceń, i command < myfile, cat myfile | command i command myfilemoże dać ten sam wynik.

Na przykład,

Gdy polecenie brzmi sed:

sed s/day/night/ <myfile >new   
sed s/day/night/ myfile >new    
cat myfile | sed s/day/night/ >new

Gdy polecenie brzmi cat:

cat < myfile
cat myfile

1. Zastanawiałem się, czy istnieją jakieś ogólne zasady dotyczące ich występów, tj. Która z nich jest zwykle najbardziej wydajna, a która najmniej?
2. Czy przekierowanie jest zawsze lepsze niż potok?

cat file | commandSkładnia jest uważany za Useless użycieCat . Ze wszystkich opcji wymaga wydajności, ponieważ musi odrodzić inny proces w jądrze. Jakkolwiek nieistotne może się to okazać na dużym obrazie, jest to narzut, którego nie mają inne formy. Zostało to omówione na pytania takie jak: Czy powinienem dbać o niepotrzebne koty?

Między pozostałymi dwiema postaciami praktycznie nie ma różnic w wydajności. STDIN to specjalny węzeł pliku, który proces musi otwierać i czytać tak jak każdy inny. Przekazanie nazwy pliku zamiast STDIN powoduje po prostu otwarcie innego pliku.

Różnica polegałaby na tym, jakich funkcji / elastyczności szukasz.

• Przekazanie nazwy pliku do programu oznaczałoby, że plik wejściowy byłby widoczny. To może, ale nie musi mieć znaczenia dla programu, ale niektóre operacje można przyspieszyć, jeśli strumień jest widoczny.
• Znajomość rzeczywistego pliku wejściowego pozwala Twojemu programowi na potencjalnie zapis do niego. Na przykład sed -ido edycji w miejscu. (Uwaga: ponieważ musi to utworzyć nowy plik za kulisami, nie jest to wzrost wydajności w porównaniu z innymi przekierowaniami, ale jest to krok wygody.)
• Korzystanie z przekierowań powłoki umożliwia łączenie wielu plików, a nawet przekierowywanie procesów. sed [exp] < file1 file2a nawet sed [exp] < <(grep command). Szczegóły tego przypadku użycia można znaleźć w tym pytaniu: Podstawienie procesu i potok

1. Biorąc pod uwagę, że command filepo prostu otwiera plik i od tego momentu działa tak, jakby był stdin, nie ma różnicy. Dzięki przekierowaniu powłoki po prostu wcześniej otwierasz plik (shell robi,) w przeciwieństwie do samego polecenia binarnego.

2. Jeśli mówimy o cat file | command kontra command <file, to ten drugi jest preferowany. Nie zauważysz znaczącej różnicy wydajności między tymi dwoma, ale ta pierwsza jest niepotrzebnie skomplikowana (dodatkowy proces i bufor pamięci współdzielonej dla potoku, z ograniczoną przepustowością.) Ponadto nie możesz seek(arbitralnie zmienić pozycji wskaźnika pliku) w potoku, podczas gdy możesz w zwykłym pliku. Niektóre polecenia mogą wykorzystywać bardziej wydajny algorytm, gdy seekmożliwe jest -ing w pliku wejściowym.