Autor: Leszek Gerwatowski (bigl_at_tg.com.pl)
Data: Tue 20 Jan 1998 - 18:01:57 MET
On Mon, 19 Jan 1998, Jan Stožek wrote:
> :>> 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...
>
>
A to juz jest zagadka programistow IBM :-(
__________________
Leszek Gerwatowski
bigl_at_tg.com.pl
__________________
... Press any key to continue or any other key to quit.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:16:02 MET DST