Re: slaby komp, dodać procent wydajności

Użytkownik "Grzegorz Niemirowski" <gnthexfiles@poczta.onet.pl> napisał w
wiadomości news:h8l9ls$1sv$1@opal.icpnet.pl...
> Sempiterna <rzopa@amorki.pl> napisał(a):
>> Między samymi systemami plików różnice są poniżej błędu
>> statystycznego.
>
> LOL. Nie mów, że wyszukiwanie liniowe zajmuje tyle samo czasu co w
> B-drzewie.

Nie mówię. Jednak przy przeciętnej ilości plików w katalogu, buforowaniu
odczytu, dla mniejszych objętości różnica dla przecietnego użytkownika
będzie niewielka. Natomiast przy rzeczywiście dużej ilości plików, nawet
buforowanie w końcu polegnie, a bez buforowania, to tragedia. Robiłem,
dość dawno temu próby, FAT32 OIDP, do katalogu wpychałem więcej, niż
32767 plików. Dało się. Ale już od ok. tysięcznego znać było
spowolnienie, a od 10 tysięcy po prostu muliło. Dość powiedzieć, zę z
buforowaniem (!) dostęp do 30-tysięcznego pliku w kolejce trwał nawet
pół minuty. Bez tego, to i po 5 minutach jeszcze dostępu nie było, a
dysk rzęził od pofragmentowania katalogu. W NTFS spowolnienie od takiej
ilości plików jest niemal nieodczuwalne, możeto potrwa do 1 sekundy, a i
to raczej dlatego, że musi namyślić się program, musi wywołać
podprogram... Przy bezpośrednim wywołaniu pliku czas jest prawie
niemierzalny.
Tak, Grzegorz, znam tę różnicę. Ale, jak wspomniałem, jaskrawo wychodzi
ona raczej przy ilościach plików na codzień nie spotykanych. Tak do
tysiąca, to raczej buforowanie pokryje...
Robiłem działania, gdzie w katalogu miałem do 30, może nawet 60 tysięcy
plików, nie odczuwałem żadnego dyskomfortu związanego z ilością. Może
kiedyś porobię jeszcze próby z większymi ilościami, jak to wpływa na
czas dostępu do pliku.
PS. Poza tym, nie widzę przeszkód, by na bieżąco indeksować także
katalogi FAT32, choć oczywiście, nie będzie to tak proste, jak w
systemie, w który to jest wbudowane... Ale skoro daje się zrobić
linuxowe prawa dostępu na partycji MS-DOS... To miało by się nie dać z
Windą i FAT32? Klucz widzę w przyjętym przez Pingwina rozwiązaniu -
dodatkowym pliku z długimi nazwami i atrybutami dostępu, niewidocznym
spod Linuxa. Tak, wiem, że to proteza. Ale co, nie da się w nim
zindeksować zawartości katalogu? System przezroczyście mógłby
przykrywając ten plik, analizować go i wskazaną pozycję wpisu katalogu
przeliczać przez łańcuch alokacji, co umożliwiało by szybki skok do
żądanej pozycji, bez przemielenia się przez pozostałe... Poza tym, ja z
innego powodu nie bardzo wyobrażam sobie liniowego szukania w NTFS -
wpis pliku w tym systemie zajmuje przeciętnie 1 kB, a przeciętny wpis
pliku FAT32, to hmm, 4 miejsca na starą nazwę, powiedzmy, 128 bajtów, do
256 jeśli dłuższa nazwa. Więcej danych do przemielenia w NTFS (no, jeśli
szukany plik jest na 49563 pozycji, a po drodze jeszcze ze 20 tysięcy
skasowanych wpisów? śjakieś 70 MB do przemiału, a to potrwa zauwazalnie
długo nawet na najszybszych dyskach SSD), chyba, że opracować
technologię, umożliwiającą wstrzelenie się w sektor od razu do środka,
bez wczytywania w całości... a to się nie da, zresztą, i tak wymagało by
to chyba zindeksowania... więc wracamy do wyjścia... Jedyne sensowne, co
wydaje mi się w miarę proste do zrobienia, to dołożenie indeksowania
plików do FAT32, NTFS ma już co trzeba i lepiej nie rzeźbić (choć
czytałem, ze drzewko binarne w nim rozrasta się za bardzo na boki).

-- 
"E, tam, oszukaństwo, oszukaństwo... Zwyczajna polityka!"
(C) Kazimierz Pawlak, do Kargula, o pomalowanej czarną pastą świni;
"Nie ma mocnych" - druga część tryptyku.