Czy liczba plików w jednym katalogu ma znaczenie dla wydajności?

Kiedyś w programach, które odwoływały się do znacznej liczby małych plików, był zwyczaj dzielenia tych plików na katalogi/foldery po np. kilkadziesiąt elementów.

Np. wszystkie pliki na literę e w folderze \e, wszystkie zaczynające się na f w folderze \f itd. W każdym razie unikano sytuacji, w której w jednym folderze są tysiące plików.

Z poziomu eksploratora w Windows wielotysięczny katalog otwierał się zauważalnie dłużej. Podobno miało to wynikać z niedostatecznego cache dysku...

Czy dziś z jakichś powodów wydajnościowych warto jest dzielić katalogi z liczbą np. 10 tysięcy plików na mniejsze (np. 100 katalogów po 100 elementów)? Czy program, który odwołuje się do pojedynczego pliku znajdującego się w katalogu np. 100-elementowym będzie wydajniejszy od takiego, który ma 10 tysięcy elementów w jednym folderze?

Teoretycznie tak, ale w praktyce różnica nie powinna być zauważalna.

A z czego ta różnica zasadniczo wynika? Jeśli otwieram cały folder z 10000 obiektów, to mogę sobie wyobrazić, że głowice w HDD muszą się nabiegać zanim ogarną to wszystko, ale gdy program poprzez zapisane ścieżki odwołuje się w jednym czasie tylko do jednego lub dwóch elementów potrzebnych z tej liczby, to z czego różnica wynika?

Folder to mniej więcej mapa nazw na np fizyczną lokalizację pierwszego sektora pliku. Ta mapa może być zaimplementowana za pomocą zwykłej listy lub za pomocą np drzewa. FAT używa chyba zwykłych list, jeśli lista nie mieści się w jednym klastrze na dysku to może być dodatkowo pofragmentowana.

Wyobraź sobie, że folder to tablica. Żeby znaleźć w tej tablicy odpowiedni element trzeba ją przeszukać. Im więcej elementów do przeszukania tym dłużej to trwa.

Brzmi logicznie, choć myślałem, że gdy program wrzuca ścieżkę do konkretnego elementu, to ona od razu naprowadza na właściwe miejsce, bez przechodzenia w tym wypadku przez pełną tablicę. Cóż trzeba będzie dzielić. Dzięki za odpowiedzi.

Brzmi logicznie, choć myślałem, że gdy program wrzuca ścieżkę do konkretnego elementu, to ona od razu naprowadza na właściwe miejsce, bez przechodzenia w tym wypadku przez pełną tablicę.

Zależy, dużo systemów plików trzyma ważniejsze odnośniki na początku, wobec czego można iść na skróty. Również z tą tablicą jest średnio prawdziwie, bo mi się wydaje że to bardziej zależy od ilości folderów, nie wszystkiego.

Jeżeli chodzi o wydajność, to mi się wydaje że na dwoje babka wróżyła. Różnice nie będą zbyt duże, bo i tak i tak będzie wolno. A zastanawianie się jak jest szybciej jest bez sensu, bo mnogość technologii powoduje że dane będą różne na różnych konfiguracjach.
Natomiast żeby było szybciej, trzeba czytać duże pliki i ma ich być mało. Wiadomo że wolniej się czyta 100 plików po 1kb niż 2 pliki po 50kb.

lukasz1235 napisał(a)

Wyobraź sobie, że folder to tablica. Żeby znaleźć w tej tablicy odpowiedni element trzeba ją przeszukać. Im więcej elementów do przeszukania tym dłużej to trwa.
Ale przecież tak nie jest w nowszych systemach plików. To nie jest tablica tylko drzewo czy jakaś hasztablica. Samo dzielenie na podfoldery nic nie daje, gdyż mimo nieznacznego skrócenia czasu wyszukiwania pliku w danym folderze nieznacznie zwiększamy czas wyszukania samego folderu.

Może warto rozmawiać na gruncie konkretnych systemów plików. Najbardziej interesuje mnie oczywiście NTFS.

http://stackoverflow.com/questions/197162/ntfs-performance-and-large-volumes-of-files-and-directories

If you're looking at 100K entries, no worries. Go knock yourself out. If you're looking at tens of millions of entries

Czyli problem istnieje, ale nie przy omawianym rzędzie wielkości 10000 elementów.

Najlepszym sposobem będzie wykonanie kilku(nastu) prób, żeby się czegoś konkretniej dowiedzieć; Napisz kilka algorytmów, dzięki którym będziesz mógł przetestować różne warianty uwzględniając czas wyszukiwania dla danej liczby plików i katalogów; Teoria nie zawsze idzie w parze z praktyką;

Azarien napisał(a)

Go knock yourself out.

Fajnie guglowy tłumacz rozpoznał ten tekst:

translate.google.pl napisał(a)

Pukać się na zewnątrz.

Nie bardzo wiedziałem co to znaczy i sprawdziłem, ale i tak nie chce mi się w to wierzyć :P
Wie ktoś co to naprawdę znaczy...?

Teoria nie zawsze idzie w parze z praktyką;

Jeśli teorię masz zwaloną to na pewno nie.

Wie ktoś co to naprawdę znaczy...?

http://www.urbandictionary.com/define.php?term=knock%20yourself%20out
W tym przypadku chodzi mniej więcej o to, żeby się nie spinać.

Wibowit napisał(a)

Jeśli teorię masz zwaloną to na pewno nie.

Nie zawsze; Nie podam Ci teraz przykładów, ale zdarza się, że w praktyce różnie to wychodzi; Wszystko zależy od tego, kto opracował daną teorię i na jakiej podstawie;

Wibowit napisał(a)

W tym przypadku chodzi mniej więcej o to, żeby się nie spinać.

Szkoda, że gugl tłumacz nie zna slangu... :P