Dlaczego polecenie „znajdź | grep „nazwa pliku” ”o wiele wolniej niż„ znaleźć ”nazwę pliku?

Próbowałem obu poleceń, a polecenie find | grep 'filename' jest wiele razy wolniejsze niż proste find 'filename' polecenie.

Jakie byłoby właściwe wytłumaczenie tego zachowania?

(Zakładam, że GNU findtutaj)

Używam tylko

find filename

byłoby szybkie, ponieważ zwróciłoby się po prostu filename, lub nazwy w środku, filenamejeśli jest to katalog, lub błąd, jeśli ta nazwa nie istniała w bieżącym katalogu. Jest to bardzo szybka operacja, podobna do ls filename(ale rekurencyjna, jeśli filenamejest katalogiem).

W przeciwieństwie,

find | grep filename

pozwoli findwygenerować listę wszystkich nazw z bieżącego katalogu i poniżej, które grepnastępnie zostaną odfiltrowane. Byłoby to oczywiście znacznie wolniejsze działanie.

Zakładam, że to, co faktycznie było zamierzone, było

find . -type f -name 'filename'

Będzie to wyglądało filenamejak nazwa zwykłego pliku w dowolnym miejscu w bieżącym katalogu lub poniżej.

Będzie to tak szybkie (lub porównywalnie szybkie), jak find | grep filename, ale greprozwiązanie będzie pasować filenamedo pełnej ścieżki każdej znalezionej nazwy, podobnie do tego -path '*filename*', co by to zrobiło find.

Zamieszanie wynika z niezrozumienia sposobu finddziałania.

Narzędzie pobiera wiele ścieżek i zwraca wszystkie nazwy poniżej tych ścieżek.

Następnie możesz ograniczyć zwracane nazwy za pomocą różnych testów, które mogą oddziaływać na nazwę pliku, ścieżkę, znacznik czasu, rozmiar pliku, typ pliku itp.

Kiedy powiesz

find a b c

poprosisz findo podanie wszystkich nazw dostępnych w ramach trzech ścieżek a, boraz c. Jeśli są to nazwy zwykłych plików w bieżącym katalogu, zostaną one zwrócone. Jeśli którykolwiek z nich jest nazwą katalogu, zostanie on zwrócony wraz ze wszystkimi dalszymi nazwami w tym katalogu.

Kiedy robię

find . -type f -name 'filename'

Generuje to listę wszystkich nazw w bieżącym katalogu ( .) i poniżej. Następnie ogranicza nazwy do zwykłych plików, tj. Nie katalogów itp -type f. Za pomocą . Następnie istnieje dalsze ograniczenie nazw, które pasują filenameprzy użyciu -name 'filename'. Ciąg filenamemoże być wzorcem globowania nazw plików, takim jak *.txt(pamiętaj, żeby go zacytować!).

Przykład:

Następujące zdaje się „znajdować” plik wywołany .profilew moim katalogu domowym:

$ pwd
/home/kk
$ find .profile
.profile

Ale w rzeczywistości zwraca wszystkie nazwy na ścieżce .profile(jest tylko jedna nazwa, i to z tego pliku).

Następnie cdprzechodzę na wyższy poziom i próbuję ponownie:

$ cd ..
$ pwd
/home
$ find .profile
find: .profile: No such file or directory

findKomenda teraz nie mogę znaleźć żadnej ścieżki nazwie .profile.

Jeśli jednak popatrzę na bieżący katalog, a następnie ograniczę tylko zwrócone nazwy.profile , znajdzie je również stamtąd:

$ pwd
/home
$ find . -name '.profile'
./kk/.profile

Wyjaśnienie nietechniczne: Szukanie Jacka w tłumie jest szybsze niż szukanie wszystkich w tłumie i eliminowanie wszystkich z wyjątkiem Jacka.

Nie zrozumiałem jeszcze problemu, ale mogę dostarczyć więcej informacji.

Podobnie jak w przypadku Kusalanandy, find | greppołączenie jest wyraźnie szybsze w moim systemie, co nie ma większego sensu. Początkowo przyjąłem problem buforowania; zapisywanie na konsoli spowalnia czas do następnego wywołania systemowego w celu odczytania nazwy następnego pliku. Pisanie do potoku jest bardzo szybkie: około 40 Mb / s nawet w przypadku zapisu 32-bajtowego (w moim raczej wolnym systemie; 300 MiB / s dla bloku o wielkości 1 Mb). W związku z tym założyłem, że findmożna szybciej czytać z systemu plików podczas zapisywania do potoku (lub pliku), aby dwie operacje odczytujące ścieżki plików i zapisujące do konsoli mogły działać równolegle (czego findjako proces pojedynczego wątku nie może wykonać samodzielnie.

To findwina

Porównywanie dwóch połączeń

:> time find "$HOME"/ -name '*.txt' >/dev/null

real    0m0.965s
user    0m0.532s
sys     0m0.423s

i

:> time find "$HOME"/ >/dev/null

real    0m0.653s
user    0m0.242s
sys     0m0.405s

pokazuje, że findrobi coś niesamowicie głupiego (cokolwiek to może być). Po prostu okazuje się, że jest dość niekompetentny w wykonywaniu -name '*.txt'.

Może zależeć od stosunku wejścia / wyjścia

Możesz pomyśleć, że find -namewygrywa, jeśli jest bardzo mało do napisania. Ale jest coraz bardziej zawstydzające find. Traci nawet, jeśli nie ma nic do zapisania w stosunku do 200 000 plików (13 mln danych potoku) dla grep:

time find /usr -name lwevhewoivhol

findmoże być jak najszybciej grep, choć

Okazuje się, że findgłupota namenie obejmuje innych testów. Zamiast tego użyj wyrażenia regularnego, a problem zniknął:

:> time find "$HOME"/ -regex '\.txt$' >/dev/null     

real    0m0.679s
user    0m0.264s
sys     0m0.410s

Myślę, że można to uznać za błąd. Czy ktoś chce zgłosić błąd? Moja wersja to find (GNU findutils) 4.6.0

Uwaga : Zakładam, że masz na myśli find . -name filename(w przeciwnym razie szukasz różnych rzeczy; find filenamefaktycznie szuka ścieżki o nazwie nazwa_pliku , która może nie zawierać prawie żadnych plików, a zatem wychodzi bardzo szybko).

Załóżmy, że masz katalog zawierający pięć tysięcy plików. W większości systemów plików pliki te są faktycznie przechowywane w strukturze drzewa , co pozwala szybko zlokalizować dowolny plik.

Więc kiedy pytasz find, aby zlokalizować plik, którego nazwa wymaga jedynie sprawdzenie, findbędą prosić o tym pliku, a jedynie, że plik, do systemu plików bazowych, które będą czytać bardzo kilka stron z pamięci masowej. Jeśli więc system plików jest wart swojej soli, ta operacja będzie przebiegać znacznie szybciej niż przemierzanie całego drzewa w celu pobrania wszystkich wpisów.

Kiedy prosisz o proste, findjednak dokładnie to robisz, przemierzasz całe drzewo, czytając. Każdy. Pojedynczy. Wejście. W przypadku dużych katalogów może to stanowić problem (jest to dokładnie powód, dla którego kilka programów, które muszą przechowywać wiele plików na dysku, utworzy „drzewa katalogów” o głębokości dwóch lub trzech składników: w ten sposób każdy liść musi zawierać tylko mniej akta).

Załóżmy, że istnieje plik / john / paul / george / ringo / beatles, a szukany plik nazywa się „kamieniami”

find / stones

find porównuje „beatles” do „stones” i upuszcza go, gdy „s” i „b” nie pasują.

find / | grep stones

W tym przypadku find przejdzie „/ john / paul / george / ringo / beatles” do grep i grep będzie musiał przejść przez całą ścieżkę przed ustaleniem, czy pasuje.

grep wykonuje zatem znacznie więcej pracy, dlatego zajmuje więcej czasu