Re: Defragmentacja pliku wymiany (Win7 32bit)

Autor: L501 aneryS <spam.nie.jest_at_spoko.pl>
Data: Thu 02 Feb 2012 - 04:11:11 MET
Content-Type: text/plain; format=flowed; charset="iso-8859-2"; reply-type=response
Message-ID: <4f29fed3$1@news.home.net.pl>

Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości
news:2012020120182800@grush.one.pl...
>W dniu 29.01.2012 23:15, L501 aneryS pisze:
>> Użytkownik "Radosław Sokół" <rsokol@magsoft.com.pl> napisał w wiadomości
>> news:2012012910075400@grush.one.pl...
>>> Dla pliku wymiany transfer sekwencyjny jest prawie całkowicie
>>> nieistotny, bo ten plik jest mocno sfragmentowany wewnętrznie.
>>> Liczy się tylko średni czas dostępu.
>>
>> Łańcuch jest tylko tak mocny...
>
> Konkrety proszę, a nie okrągłe hasełka z wielokropkiem.

... jak jego najsłabsze ogniwo.

>> To mi np. sfinansuj zakup pamięci (1), skoro przy 768 RAM mam niekiedy do
>> obrobienia ponad gigabajt danych w jednym momencie. Jasne, że ja bym to
>> chciał upchnąć w pamięci. Ale nie zawsze się da. A to,
>> jak szybko mi maszyna to obrobi, zależy także od tego, jak szybko system
>> wyrzuci to na dysk, czy z niego ściągnie. Tu milisekunda, tam kilobajcik,
>> ziarko do ziarka, jak w znanym przysłowiu.
>
> Używasz niewłaściwego narzędzia do realizowanego zadania.

Było by lepsze, było by użyte.
Za dużo razy sparzyłem się na użyciu narzędzia właściwego, jak to określasz,
ale coś mu poszło nie tak, bo cuś-tam zrobiło ciut niewłaściwie, co
poskutkowało bajzlem gorszym niż słoń z odbezpieczonym granatem w trabie, w
składzie porcelany, przylegającym do stacji benzynowej.
Czasem udawało się to wyprostować, czasem jednak nie. Ja jestem jak kot.
Uzyskasz odpowiedź na pytanie, gdy zorientujesz się, czemu kot nieraz
spierdziela naokoło, przez kolczaste krzaki, mając do dyspozycji drogę
prostą, gładką, stokroć łatwiejszą, do tego bezproblemowo możliwą do
wybrania.

> Inna sprawa, że zazwyczaj tak obszerne dane obrabia się sek-
> wencyjnie, zatem jeżeli działa to wolno, to może być problem
> ze złej jakości oprogramowaniem.

No, zapewne nienajlepszej, to prawda. Jednakże, trudno jednoznacznie
określić program jako źle napisany, jeśli przy 768RAM, ilości danych >1giga,
oraz intensywnym ich przeliczaniu, system wołowacieje, a sam program niemal
ulega zmrożeniu. Wspomniałem, że łańcuch jest tak dobry, jak jego najsłabsze
ogniwo. Co z szybkiego procka, szybkiej pamięci, wielu rdzeni, gdy danych
jest jeszcze więcej, ponadto są porozrzucane po dysku i głowica nie dość, że
musi między nimi skakać, to jeszcze między kawałkami swapa, niemal
jednocześnie. No, nie wymagaj(my) od programu, by w takich warunkach dobrze
mu się działało. A jeszcze jak dysk jest powolny... Możemy algorytmami
użytymi przy programowaniu pewne rzeczy zoptymalizować, ale nic za darmo nie
ma, przecież to jest jasne. Dane mogą być ułożone sekwencyjnie, ale nie
muszą, czasem może być konieczne posortowanie kilkuset tysięcy (i więcej)
sporych pozycji. Na coś takiego słusznym wydaje mi się ich zindeksowanie,
nie na darmo NTFS ma tak wysoką wydajność, że mimo wielkiego postępu w
informatyce, będąc tak wiekowym systemem plików, nadal jest stosowany (a
nawet chyba się rozwija) i jakoś nic nie zapowiada jego porzucenia.

-- 
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.
Received on Thu Feb 2 04:15:02 2012

To archiwum zostało wygenerowane przez hypermail 2.1.8 : Thu 02 Feb 2012 - 04:42:01 MET