Autor: Michal Kawecki (kwinto_at_2com.pl)
Data: Sun 02 Mar 2003 - 21:13:52 MET
Użytkownik "Peterphk" <peterphk.no-fq-spam_at_poczta.onet.pl> napisał w
wiadomości news:b3tkeb$3oj$1_at_absinth.dialog.net.pl
>
>> Link do artykułu:
>>
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/colum
>> ns/bong/windows2000/default.asp
>> (albo http://tinylink.com/?hA8c2wHGDj)
>>
>> Poza tym można sporo przyspieszyć dostęp do danych w NTFS poprzez:
>> wyłączenie uaktualniania czasu ostatniego dostępu, wyłączenie
>> tworzenia DOS-owych, krótkich nazw plików,
>
> to samo moznaby zrobic z FAT32 ... jezeli juz porownywac to uczciwie
> ...
Porównanie w powyższym artykule było uczciwe. Autor nie sięgał tam do
takich nieprzyzwoitych metod ;-). A ja tylko dopisałem, jak można
jeszcze przyspieszyć NTFS...
>
>> przyzwoitą regularną defragmentację MFT
>> i katalogów, umieszczenie MFT bliżej połowy partycji (tak jak robi to
>> obecnie XP w NTFS 5.1) i - co istotne - w jednym lub najwyżej kilku
>> kawałkach. Warto też wypróbować wbudowaną kompresję - pliki się
>> szybciej otwierają.
>
> No tutaj to chyba zarty sobie robisz. Przeciez to nie dysk
> dekompresuje te dane tylko system!! Jezeli ktos ma P4 3GHz to pewnie
> to dla niego bez roznicy bo i tak nie odczuwa, ze cos wolno chodzi,
> ale na slabszych sprzetach kompresja danych obciaza dodatkowo system
> i nie trzeba specjalnie sie wpatrywac zeby to zauwazyc. Kazda
> kompresja danych bedzie opozniala czas dostepu do danych (co wplywa
> ujemnie na prace z wieloma plikami).
>
Mylisz się. Procesor jest obciążany głównie kompresją, wtedy wykonuje
solidną pracę, natomiast sam proces dekompresji odbywa się
błyskawicznie. Porównaj nakład czasu pracy procesora niezbędny np. na
kompresję do MP3 i obciążenie procesora podczas dekompresji tego
formatu. Nie jest ona na pewno żadnym problemem dla procesora, tym
bardziej, że procesory w dzisiejszych (wcale nie topowych) maszynkach
się w zasadzie nudzą ;-). A przyspieszenie uzyskujesz dlatego, bo zawsze
szybciej jest odczytać dwa bajty i rozpakować je w pamięci do
kilkudziesięciu kilobajtów informacji (to skrajny przykład, kiedy
odczytujemy np. same zera), niż te same kilkadziesiąt kB informacji
wczytać klaster po klastrze z dysku. Szczególnie, gdy plik jest
podzielony na kilka fragmentów, a każdy z nich zabiera ileś tam
milisekund czasu na pozycjonowanie głowic. Jak tych plików jest mało, to
można powiedzieć: no problem, jest cache dysku. Ale co z szukaniem po
zupełnie przypadkowych plikach?
>> Natomiast prawdą jest, że małe partycje FAT32 z małą ilością plików
>> będą szybsze od NTFS. Z tym, że jeśli w komputerze będzie
>> wystarczająca ilość RAM, to ta różnica sięgnie... raptem kilku
>> procent ;-).
>
> Jezeli mala partycja to 40GB no to moze byc prawda:))) ale nie jest to
> roznica kilka procent. Poza tym jakby wierzyc we wszystko co pisza na
> stronie microsoftu to swiat bylby pelen optymistow ...:)
Ja to ujmę inaczej: w idealnych warunkach nie ma w zasadzie różnic
prędkości pomiędzy NTFS a FAT32, tak wynika z obmiarów. Te różnice
występują w świecie realnym, bo każdy user inaczej dba o system, każda
partycja jest inaczej zbudowana (klastry, fragmentacja MFT), a konkretne
dane na niej mogą lepiej się czytać akurat w określonym systemie plików
i w określonych aplikacjach. Jeśli jednak ktoś mówi o DUŻEJ różnicy
prędkości, znaczy powiedzmy 30% do 100%, to podejrzewałbym raczej
skrajny brak obiektywizmu :-). Albo nieoptymalną konfigurację systemu...
M.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 09:35:03 MET DST