Co zmieniło widok listy Findera w Lionie, aby „Oblicz wszystkie rozmiary” wykładniczo szybciej?


10

Od czasu, gdy na scenie pojawił się Mac OS X, byliśmy w stanie poprosić Findera o obliczenie wszystkich rozmiarów w celu ustalenia całkowitej sumy czytelnej przestrzeni wielkości pliku zawartej w każdym folderze dla danego okna Findera.

Finder - widok listy - pokaż opcje widoku - Oblicz wszystkie rozmiary

Przetestowałem rozmiar folderów w widoku listy na kilku komputerach Mac, gdzie nie ma znaczenia, czy dysk SSD jest obecny, czy nie, ale Lion tak szybko oblicza rozmiary, jestem ciekawy, czy istnieje nowa struktura danych buforowania lub czy Finder używa informacje o metadanych z Spotlight lub podobnej bazy danych, aby znacznie przyspieszyć te obliczenia.


1
Skąd masz to okno? Oparty na przycisku „Użyj jako domyślnych” na dole wygląda jak okno „Pokaż opcje widoku” (<kbd> ⌘J </kbd>), ale nie mogłem nic pokazać w dolnej części.
Cajunluke

1
@ CajunLuke należy otworzyć widok okna na listę przed otwarciem okna „Pokaż opcje widoku”.
pdd

Odpowiedzi:


3

Nie zauważyłem, że Lion jest szybszy w obliczaniu rozmiarów folderów (i paczek / pakietów) podczas pierwszego obliczania rozmiarów w folderze. Jednak kolejne obliczenia w tym samym folderze wydają się znacznie szybsze.

Częścią postrzeganej szybkości może być to, że Finder natychmiast pokaże wcześniej obliczone rozmiary szarym tekstem, podczas gdy ponownie oblicza rozmiary folderów, zamiast pokazywać „-”, dopóki nie zostanie obliczony. Po ponownym obliczeniu rozmiaru folderu numer zostanie zaktualizowany (jeśli rozmiar się zmienił) i zmieni kolor na czarny.

Ponieważ Finder w sposób zauważalny buforuje wcześniej obliczone rozmiary folderów, możliwe jest, że ponownie oblicza tylko rozmiary folderów, które zmieniły się od czasu ostatniego obliczenia.


Myślę, że to sedno problemu. Buforowanie jest znacznie lepsze, a częściowe lub nieaktualne wyniki są wyświetlane przyrostowo. Nie wiem, czy algorytm jest poprawiony, aby wypełnić widoczne dane, ale samo buforowanie wydaje się być odpowiedzią na moją przyjemność z tego, jak działa teraz w praktyce.
bmike

Po kilku miesiącach uważnego obserwowania tego masz całkowitą rację. Mechanizm buforowania jest teraz tak dobry, że na komputerach Mac, z których korzystałem przez jakiś czas, dane te są prawie zawsze poprawne i natychmiastowe. Tylko na nowym komputerze Mac krótko po ponownej instalacji lub konfederacji zauważalna jest starsza prędkość, ponieważ system operacyjny musi całkowicie zebrać informacje.
bmike

7

Przed Lionem w kolumnie Rozmiar pliku w Finder.app był wyświetlany rozmiar każdego pliku wymagany na dysku twardym, a nie dokładny rozmiar pliku. Na przykład 1 bajtowe pliki były wyświetlane jako 4 KB, ponieważ w rzeczywistości zajmują 4 KB miejsca w systemie sformatowanym w systemie HFS. Rzeczywisty rozmiar pliku 1 bajt nie był łatwy, inny niż otwarcie Plik ›Uzyskaj informacje (lub użycie innej aplikacji, takiej jak Terminal.app, a następnie użycie ls -lsalub zamiana Finder.app, takiej jak TotalFinder.app ).

(Powrót w dzień, zgłosiłem to jako bug 8926275 na bugreport.apple.com ).

Począwszy od Lion, to zachowanie zostało poprawione, a kolumna Rozmiar pliku pokaże teraz dokładny rozmiar każdego pliku, a nie rozmiar przydzielany na dysku twardym (który i tak zależy od systemu plików).

Ponieważ te rozmiary to te same liczby, które można uzyskać z lspliku binarnego w terminalu, ich obliczenia są znacznie wydajniejsze.


1
To także niesamowity szczegół. Ponieważ dyski SSD stają się coraz bardziej powszechne, a pamięć masowa staje się bardziej wyrafinowana dzięki migawkom, przypuszczam, że minęło już wiele czasu, ponieważ przestałem martwić się o ilość miejsca zajmowanego przez określoną instancję pliku i po prostu martwiłem się o logiczny rozmiar plików w przeciwieństwie do fizycznego.
bmike

Nie rozumiem tego Jak to jest bardziej wydajne? Czy pojedyncze stat(2)połączenie nie jest odpowiedzialne za odzyskanie obu numerów? I w ls(1)ogóle nie pokazuje rzeczywistego rozmiaru pakietów / pakietów / folderów, więc nie mam pojęcia, dlaczego to jest istotne.
Ken

@Ken lspokazuje rozmiary plików w porządku dla zwykłych plików. statmożna zrobić to samo dla pojedynczego pliku. Chodzi mi o to, że „dodatkowa praca” potrzebna do obliczenia rozmiarów pakietów / pakietów / folderów jest teraz potrzebna tylko dla pakietów / pakietów / folderów, a nie dla zwykłych plików.
Mathias Bynens,

Mathias: Tak, lspokazuje rozmiary plików dla zwykłych plików, a nie pakietów (tak powiedziałem). Robi to dzwoniąc stat. Jaka „dodatkowa praca” była wcześniej wymagana w przypadku zwykłych plików? Pojedyncze statwywołanie zwraca oba bloki ( st_blocks) i bajty ( st_size).
Ken

1

Nie zdziwiłbym się, gdyby używali metadanych Spotlight do buforowania rozmiarów plików. Jeśli już używasz FSEventów do śledzenia wszystkich zmian w systemie plików i (potencjalnie) Time Machine, aby wykonać kopię zapasową wszystkich tych zmian, dodatkowy koszt obliczania i przechowywania zbiorczych rozmiarów plików jest znikomy.


Zobaczę, czy mogę fs_events rozlać ziarna, jeśli są to metadane lub w inny sposób. Chciałbym, żeby czytał dane w centrum uwagi - ale nie mam jeszcze bezpośrednich dowodów.
bmike

1

Począwszy od OS X Lion, Apple dodał bazę danych SQLite, której system operacyjny używa do śledzenia plików w funkcjach systemu, takich jak Spotlight. Kwerendowanie z bazy danych SQLite zamiast sprawdzania systemu plików za każdym razem jest bardziej niż prawdopodobne przyczyną poprawy wydajności. Recenzja Johna Siracusa na OS X Lion szczegółowo wyjaśnia zmiany w systemie plików w Lionie. W szczególności tutaj znajdziesz wyjaśnienie dotyczące nowej bazy danych SQLite.

Mam nadzieję że to pomoże.


Jest to bardzo miłe łącze, jednak baza danych SQLite pojawia się na wszystkich moich komputerach Mac, aby śledzić tylko dokumenty, które mają wersje, które są małym podzbiorem wszystkich plików na dysku. Jeśli możesz znaleźć link do bazy danych, która przechowuje wszystkie rozmiary plików, to co najmniej interesujące, ponieważ system plików jest już bazą danych, aby to zrobić, prawda?
bmike
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.