dlaczego Nautilus jest wolny?

Zastanawiam się, dlaczego Nautilus działa bardzo wolno podczas otwierania katalogu zawierającego wiele plików. Na przykład mój katalog / usr / lib ma 1900 plików i wyświetlenie wszystkiego zajmuje około 5 sekund. Tak było, odkąd zainstalowałem Ubuntu kilka miesięcy temu i czasami jest to naprawdę dość irytujące. Nie mam potężnego sprzętu, ale wiem, że Eksplorator Windows jest o wiele szybszy.

Czy można coś zrobić, aby przyspieszyć?

Ubuntu 10.04

Śledzenie wykonania nautiluspokazuje, że powolność wynika z kombinacji dwóch czynników:

• Inteligentnie wyświetla przydatne informacje o każdym pliku. Przeszukuje zawartość plików, aby określić, jakiej ikony użyć, i ewentualnie wyświetlić podgląd. Można to złagodzić, wyłączając podgląd w preferencjach.

• Wykonuje wiele bezużytecznej pracy (np. statWielokrotne wprowadzanie każdego pliku i sprawdzanie, czy /proc/filesystemsnie ma katalogów innych niż katalogi). Wszystko, co możesz zrobić, to nauczyć się programowania, ulepszyć program i wysłać łatkę. Lub przynajmniej wyślij autorom zapytanie o funkcję (zrób to szybciej).

• Wywołuje kilka procesów zewnętrznych dla każdego katalogu, nie zbadałem, co robią.

Na karcie „Podgląd” w „Edycja -> Preferencje” spróbuj zmienić wszystkie opcje na „Nigdy”.

Ogromnie pomogło mi to wyłączyć „Technologie wspomagające”. Możesz to zrobić w „System -> Preferencje -> Technologie wspomagające”. Odznacz „Włącz technologie pomocnicze”.

Musisz się wylogować i zalogować ponownie, aby ta ostatnia zmiana zaczęła obowiązywać.

Przypomniało mi to rozmowę z Alexandrem Larssonem , głównym programistą Nautilus i innych projektów, w tym GVFS.

Odpowiedź Gilesa , a konkretnie tego, że Nautilus zagląda do zawartości plików, dotyka głównego powodu, dla którego Nautilus jest „wolny”. Jednak Giles nie wyjaśnia, dlaczego jest to powolne, co może być oczywiste dla niektórych, ale nie dla innych. Oto, co powiedział Alex:

Załóżmy, że zaczynasz od pustej listy, tzn. Wcale nie masz dostępu do systemu plików. Teraz powiedz, że uruchamiasz stat („/ some / dir / file”). Najpierw jądro musi znaleźć plik, który technicznie nazywa się i-węzłem. Zaczyna się od przeszukania superbloku systemu plików, który przechowuje i-węzeł katalogu głównego. Następnie otwiera katalog główny, znajduje „trochę”, otwiera to, znajduje „dir” itp., W końcu znajduje i-węzeł dla pliku.

Następnie musisz odczytać dane i-węzła. Po pierwszym przeczytaniu jest to również buforowane w pamięci RAM. Tak więc odczyt musi się zdarzyć tylko raz.

Pomyśl o HD jak o starym odtwarzaczu, gdy już znajdziesz się we właściwym miejscu z igłą, możesz szybko czytać rzeczy podczas obracania się. Jednak gdy musisz przenieść się w inne miejsce, zwane „szukaniem”, robisz coś zupełnie innego. Musisz fizycznie przesunąć ramię, a następnie zaczekać, aż talerz zacznie się obracać, aż właściwe miejsce znajdzie się pod igłą. Ten rodzaj ruchu fizycznego jest z natury powolny, więc czasy poszukiwania dysków są dość długie.

Kiedy więc szukamy? Zależy to oczywiście od układu systemu plików. Systemy plików próbują przechowywać pliki kolejno, aby zwiększyć wydajność odczytu, i generalnie próbują również przechowywać i-węzły dla jednego katalogu blisko siebie, ale wszystko zależy od rzeczy, takich jak zapis plików, fragmentacja systemu plików itp. Tak więc, w najgorszym przypadku W takim przypadku każda statystyka pliku spowoduje wyszukiwanie, a następnie każde otwarcie pliku spowoduje drugie wyszukiwanie. Dlatego właśnie tak długo trwa, gdy nic nie jest buforowane.

Niektóre systemy plików są lepsze od innych, defragmentacja może pomóc. Możesz robić pewne rzeczy w aplikacjach. Na przykład GIO sortuje odebrane i-węzły z readdir () przed stwierdzeniem ich, mając nadzieję, że liczba i-węzłów ma jakiś związek z kolejnością dysków (na ogół ma), minimalizując w ten sposób losowe wyszukiwania tam i z powrotem.

Jedną ważną rzeczą jest zaprojektowanie magazynu danych i aplikacji w celu zminimalizowania wyszukiwania. Na przykład dlatego Nautilus czyta / usr / bin jest powolny, ponieważ pliki tam na ogół nie mają rozszerzenia, dla którego musimy wykonać magiczne wąchanie. Musimy więc otworzyć każdy plik => jedno wyszukiwanie na plik => slooooow. Innym przykładem są aplikacje przechowujące informacje w wielu małych plikach, takie jak kiedyś gconf, również zły pomysł. W każdym razie, w praktyce nie sądzę, że możesz wiele zrobić, prócz ukrycia opóźnień.

Zakończył następującą notatką:

Prawdziwym rozwiązaniem tego całego dylematu jest odejście od wirujących mediów. Słyszę, że dyski SSD firmy Intel są niesamowite. Linus przysięga na nich.

:-)

W końcu zorientowałem się, co powoduje, że Nautilus jest tak wolny: zakładki.

Aby to naprawić, usuń wszystkie zakładki, uruchom ponownie, a następnie dodaj te, bez których nie możesz żyć.

Za pomocą strace zdałem sobie sprawę, że nautilus zapisuje wiele plików dla każdego widoku. Nawet pliki, których nie było w katalogu, przeglądałem podczas śledzenia. Myślę, że Nautilus próbuje wstępnie buforować te zakładki.

Miałem jeden dysk sieciowy jako zakładkę ... to mógł być powód, dla którego nautilus ładował się kilka sekund.

Spróbuj użyć alternatywnego menedżera plików, takiego jak Thunar. Thunar jest znacznie szybszy w ładowaniu wykazów katalogów i bardziej stabilny w kopiowaniu plików z mojego dysku twardego NTFS na ext4, chociaż przy dużych zestawach plików wydaje się, że ma problemy takie jak Nautilus.

Oto link do skryptu zmiany https://help.ubuntu.com/community/DefaultFileManager

Jeśli masz xfce zainstalowane w systemie Gnome i nigdy go nie używasz, usuń exo-utils

Naprawiono mój problem oraz problem z niepoprawnym otwieraniem plików przez Chrome po ich pobraniu.

Na karcie „Podgląd” w „Edycja -> Preferencje” spróbuj zmienić wszystkie opcje na „Nigdy”.

Ogromnie pomogło mi to wyłączyć „Technologie wspomagające”. Możesz to zrobić w „System -> Preferencje -> Technologie wspomagające”. Odznacz „Włącz technologie pomocnicze”.

Musisz się wylogować i zalogować ponownie, aby ta ostatnia zmiana zaczęła obowiązywać.