Autor: Jan Stožek (jasio_at_polbox.pl)
Data: Mon 19 Jan 1998 - 19:30:11 MET
On Mon, 19 Jan 1998 17:04:03 +0100, Leszek Gerwatowski wrote:
:>> A skąd on wie, że to już wszystkie? :)
:>>
:>
:>No idzie do konca i jezeli jeszcze jedno napotka to laduje a jak nie to
:>nie i zmienia rodzaj odwolan do ladowania.
No właśnie.
:>
:>> Gdyby się dało CONFIG wczytać w całości do pamięci i posortować
:>> w rozumie (albo i nie sortować, tylko trzymać i przeszukiwać...), to
:>> program sortujący _niczego_ by nie przyspieszył. Skoro loader jest
:>> przystosowany do losowej kolejności wierszy, to i tak musi przeszukać
:>> plik do końca, bo skąd ma wiedzieć, że jeden CONFIG jest posortowany, a
:>> drugi nie? Czyli znowu - posortowanie nie powinno znacząco przyspieszyć
:>> startu systemu. Być może całe przyspieszenie jest efektem braku cache'a
:>> w początkowym etapie startu systemu i zmniejszenia ilości seeków jakie
:>> musi wykonać dysk. Hmm... policzmy... Mój config ma jakieś 6,5 KB, czyli
:>> w najgorszym wypadku 13 bloków... czy 13 * 8 (ifs-y są ładowane w
:>> "ósmej" kolejności, po basedev, libpath, setach, codepage, country,
:>> devinfo i części device (OS/2 drivers)) * 2 (do configa i spowrotem) =
:>> 208 dodatkowych seeków... przy realnym średnim czasie dostępu 33 ms daje
:>> to prawie 7 sekund... ciekawe. Muszę to zmierzyć. :)
:>>
:>
:>To na pewno nie chodzi o to bo juz wiele razy czytalem o tym ze po
:>zastosowaniu tego programiku w drastycznych przypadkach zmiana czasu
:>ladowania byla np. z 4 minut do 2,5 minuty.
Ja też o tym czytałem. Ale ciekawe _dlaczego_ posortowanie CONFIG.SYS przyspiesza
start systemu - i to drastycznie - jeżeli loader _i_tak_ musi przeczytać cały plik do końca, wrócić,
przeczytać, wrócić, przeczytać i tak w sumie jakieś dwadzieścia razy...
Pozdrawiam serdecznie,
(js).
mailto:jasio_at_polbox.pl
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:16:01 MET DST