Autor: Peterphk (peterphk.no-fq-spam_at_poczta.onet.pl)
Data: Sun 02 Mar 2003 - 22:27:45 MET
> 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?
Jakos to mnie nie przekonuje. Pomysl co sie bedzie dzialo jak porozrzucasz
po dysku ten skompresowany plik ... komputer bedzie mial 2x wiecej roboty w
stosunku do tego jakby nie byl wogole skompresowany.
Mowimy o duzej ilosci malych plikow (czyli skanowanie np. temporary internet
files - to chyba najlepszy przyklad). Dodaj to tego np. taki przypadek, ze
pliki ktore wlasnie uzywasz slabo sie kompresuja (gif, jpeg itp.). Chyba
oczywista sprawa jest, ze dostep do takich danych bedzie prostrzy kiedy brak
jakichkolwiek kompresji ...
A tak BTW to albo optymalizuje sie system tylko do odczytu danych z dysku z
NTFS albo do normalnej pracy ... zaloze sie, ze praktycznie kazdy domowy
uzytkownik woli miec wiecej wolnego RAM'u niz szybki dostep do danych na
NTFS ... nic za darmo.
A wiec masz do wyboru:
- FAT32 i szybki dostep do plikow kosztem miejsca na dysku
- NTFS wolniejszy dostep do plikow i wiecej miejsca na HDD, ewentualnie
wariant dla serwerow czyli szybki dostep do plikow i brak wolnego RAM'u ...
> 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...
Porownaj czas zliczania plikow lub skanowania anty-virem w katalogu
temporaty internet files. Obojetnie jakbys nie zakombinowal zawsze wyjdzie,
ze na fat32 bedzie robil szybciej operacje na tym katalogu ...
Nie ma tu znaczenia jaki by byl to uzytkownik kazdy kto uzywa internetu ma
na dysku ten katalog.
Jezeli dalej ufasz microsoftowi to rozpatrz taki przypadek:
Podczas pracy z partycja ktora ma klastry 4KB procesor, zeby dobrac sie do
jednego pliku musi przeorac tysiace klastrow. Powiedzmy, ze zmniejszymy
teraz ilosc jednostek alokacji na dysku i jeden klaster ma teraz 32KB. Czy
wedlug Ciebie w systemie plikow z 4KB klastrami operacje na duzej ilosci
malych plikow beda przebiegaly szybciej niz na tym z 32KB ??? Dla mnie to
wydaje sie raczej niezbyt logiczne ...
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 09:35:04 MET DST