Dlaczego GNU znajduje się tak szybko w porównaniu z graficznymi narzędziami do wyszukiwania plików?

Próbuję znaleźć plik, który nie istnieje w moim katalogu domowym i wszystkich podkatalogach.

find ~/ -name "bogus"przekazuje mi te informacje po kilku sekundach, ale menedżer plików KDEdolphin potrzebował prawie 3 minuty, aby zrobić to samo. To odpowiada mojemu wcześniejszemu doświadczeniu z GNOMEbeagle .

Jak radzi findsobie z tym samym bardzo szybko, gdy wyszukiwanie graficzne (które jest bardziej intuicyjne w użyciu niż parametry wiersza poleceń) jest opóźnione?

Patrząc konkretnie na Dolphin z Baloo, wydaje się, że wyszukuje metadane każdego pliku w domenie wyszukiwania, nawet jeśli wykonujesz proste wyszukiwanie nazw plików. Kiedy prześledzić file.soproces, widzę wywołań lstat, getxattri getxattrznowu dla każdego pliku, a nawet do ..wpisów. Te wywołania systemowe pobierają metadane dotyczące pliku, który jest przechowywany w innym miejscu niż nazwa pliku (nazwa pliku jest przechowywana w zawartości katalogu, ale metadane znajdują się w i- węzle ). Wielokrotne sprawdzanie metadanych pliku jest tanie, ponieważ dane znajdowałyby się w pamięci podręcznej dysku, ale może istnieć znacząca różnica między pytaniem o metadane a nie pytaniem o metadane.

findjest znacznie mądrzejszy. Stara się unikać niepotrzebnych wywołań systemowych. Nie zadzwoni, getxattrponieważ nie wyszukuje na podstawie rozszerzonych atrybutów. Podczas przeglądania katalogu może być konieczne wywołanie lstatniepasujących nazw plików, ponieważ może to być podkatalog do przeszukiwania rekurencyjnego ( lstatjest to wywołanie systemowe, które zwraca metadane pliku, w tym typ pliku, taki jak zwykły / katalog / symlink /…). Jednak findma optymalizacja: wie ile podkatalogów katalogu ma od jego liczby łącza i przestanie dzwoni lstatraz wie, że jest to ruch wszystkie podkatalogi. W szczególności w katalogu typu liść (katalogu bez podkatalogów),findsprawdza tylko nazwy, a nie metadane. Ponadto niektóre systemy plików przechowują kopię typu pliku we wpisie katalogu, więc findnawet nie musi dzwonić, lstatjeśli jest to jedyna potrzebna informacja.

Jeśli uruchomisz findz opcjami wymagającymi sprawdzenia metadanych, wykona więcej lstatpołączeń, ale nadal nie wykona lstatpołączenia z plikiem, jeśli nie potrzebuje informacji (na przykład dlatego, że plik jest wykluczony na podstawie poprzedniego warunku dopasowanie do nazwy).

Podejrzewam, że inne narzędzia wyszukiwania GUI, które odkrywają findkoło, są mniej sprytne niż narzędzie wiersza poleceń, które zostało poddane dekadom optymalizacji. Przynajmniej Dolphin jest wystarczająco sprytny, aby korzystać z lokalizowanej bazy danych, jeśli wyszukujesz „wszędzie” (z ograniczeniem, które nie jest jasne w interfejsie użytkownika, że ​​wyniki mogą być nieaktualne).