Szybszy Windows

Jakoś nie wydaje mi się ze mogło by to być coś bardziej skomplikowanego jak optymalizacja plików w kontekście ich rozmieszczenia. Pewnie odpowiednie ich rozmieszczenie w połączeniu ze stała defragmentacją newralgicznych plików np przed zamknięciem systemu zadba o prędkość.

Kiedyś speed disk czy turbo speed disk potrafiły dużo pomóc przy defragmentacji na wolnych dyskach <100 mega jak się umiejętnie poukładało pliki na początku dysku to wolne dyski znacznie przyspieszały Ale to było w czasach fgdzy kazdy pocięty plik wydatnie zwalniał system. Pojawiły się Windowsy komputery przyspieszyły i ludzie o tym zapomnieli tak jak o wirusach w MBR.

Nie wystarczy rozmieścić plików blisko siebie (albo inaczej: to poprawi szybkość, ale to już przecież jest znane od lat), bo co z tego, że są blisko, jeżeli pliki odczytywane wspólnie będą rozrzucone? Osobiście przypuszczam, że ten program zmienia pozycję plików, ale nie wszystkich i nie tylko zwyczajnie jeden za drugim. Przypuszczam, że może chodzić o to, by dane odczytywane jednocześnie znajdowały się na różnych talerzach dysku, i żeby te odczytywane po nich także były na różnych talerzach, ale zaraz za tymi odczytywanymi poprzednio. Mam nadzieję, że napisałem dość jasno Przynajmniej ja bym tak to zrobił, gdybym był dostatecznie kompetentny, by przekuć tę myśl na konkretny kod ;D

Przypuszczam, że może chodzić o to, by dane odczytywane jednocześnie znajdowały się na różnych talerzach dysku

Wydawało mi się że tak robi się już od lat...

Tutaj poruszono jedynie kwestie uruchamiania.

Rozwiązanie jakie można zastosować jest następujące.

Pliki wczytywane w czasie startu systemu ułożyć w postaci jednego bloku danych na początku dysku w kolejności wczytywania. Można te pliki np umieścić w pliku swp (pamięci wirtualnej) w postaci jednego pliku.

Programy do defragmentacji robią podobną operację, ale:

1. Nie zwracają większej uwagi na kolejność wczytywania plików.

2. Pliki chociaż same są zdefragmentowane to już w czasie wczytywania głowica musi troche po dysku poskakać gdyż nie są ułożone w pobliżu siebie.

3. W każdym systemie są różne pliki wczytywane a programy do defragmentacji mają mało zindywidualizowane ustawienia.

Ogólnie mówiąc miałem to samo na myśli, szczególnie z tym układaniem plików na talerzach w kolejności odpowiadającej kolejności, w jakiej bedą odczytywane, a nie tylko przypadkowo jeden za drugim.

Wspomniałeś o różnych talerzach co sugerowało że to jest ten pomysł(a to już jest od dawna, pliki zapisuje się cylindrycznie od zewnątrz). Co do układania to każdy program defragmentujący jakoś układa.

wow no po prostu ekstra przyspieszenie, ludzie beda czekac 2 minuty zamiast 2,5...

z resztą hibernacja jest fajniejsza bo komputer uruchamia się jakieś 10 sekund.

Panowie ale właśnie w czasach dosa jeden z wymienionych przeze mnie programów (albo oba bo to w zasadzie było chyba nawet to samo) miał taka możliwość by zdefiniować mu kolejność plików jaka ma być po defragmentacji.

mikroos Co do tych talerzy to tak sie to odbywa od zawsze tylko ze nie wiem czy z poziomu Windowsa było by możliwe manipulowanie tym, trzeba mieć na uwadze ze dysk twardy jest w stanie maskować swoja rzeczywistą wewnętrzną strukturę fizyczną mapować ją na inna tak jak to ma w miejsce w przypadku  relokacji uszkodzonych sektorów. Fizycznie sektor jest gdzieś indziej ale to problem dysku bo na zewnątrz wygląda jak by była to (nazwijmy to tak) strukturą ciągłą.

To umieszczanie w jednym pliku tez kiedyś grali nazywało się to drvspace/dblspace to było narzędzie do kompresji dysków które pozwalało zaoszczędzić miejsce tracone w slackspace przy dużej ilości plików (tak pi razy drzwi 0.5 pojemności pojedynczego sektora/plik) i jeszcze troszkę przez kompresje. Problem jednak jest taki ze taki pojedynczy plik ma ten minus ze musi posiadać dodatkowo jakąś wewnętrzna strukturę. Co daje dodatkowy narzut na jego przeszukiwanie.

Jak dla mnie to pomysł ten musi oszczędzać czas "mechanicznej pracy" dysku a wiec tak rozmieścić dane na dysku i na tyle mało pofragmentowane by głowica wykonywała jak najmniej przeskoków. W przyadku systemu DOS który wczytywał pliki przy uruchomieniu praktycznie w przewidywalnej sekwencji odpowiednie ułożenie plików i brak fragmentacji miało znaczeni kluczowe ponieważ głowica nie wykonywała dalekich skoków które jeszcze wtedy zdarzało się ze były realizowane przez silniki krokowe a nie voice coil. I dwa identyczne komputery były się w stanie uruchamiać z rożną szybkością.   

To będzie dla mnie powielenie tego schematu Bo naprawdę jest wiele zapomnianych roziązań które kiedyś były stosowane powszechnie ale poszły w niepamięć.

Panowie ale właśnie w czasach dosa jeden z wymienionych przeze mnie programów (albo oba bo to w zasadzie było chyba nawet to samo) miał taka możliwość by zdefiniować mu kolejność plików jaka ma być po defragmentacji.

 

mikroos Co do tych talerzy to tak sie to odbywa od zawsze tylko ze nie wiem czy z poziomu Windowsa było by możliwe manipulowanie tym, trzeba mieć na uwadze ze dysk twardy jest w stanie maskować swoja rzeczywistą wewnętrzną strukturę fizyczną mapować ją na inna tak jak to ma w miejsce w przypadku  relokacji uszkodzonych sektorów. Fizycznie sektor jest gdzieś indziej ale to problem dysku bo na zewnątrz wygląda jak by była to (nazwijmy to tak) strukturą ciągłą.

 

To umieszczanie w jednym pliku tez kiedyś grali nazywało się to drvspace/dblspace to było narzędzie do kompresji dysków które pozwalało zaoszczędzić miejsce tracone w slackspace przy dużej ilości plików (tak pi razy drzwi 0.5 pojemności pojedynczego sektora/plik) i jeszcze troszkę przez kompresje. Problem jednak jest taki ze taki pojedynczy plik ma ten minus ze musi posiadać dodatkowo jakąś wewnętrzna strukturę. Co daje dodatkowy narzut na jego przeszukiwanie.

 

Jak dla mnie to pomysł ten musi oszczędzać czas "mechanicznej pracy" dysku a wiec tak rozmieścić dane na dysku i na tyle mało pofragmentowane by głowica wykonywała jak najmniej przeskoków. W przyadku systemu DOS który wczytywał pliki przy uruchomieniu praktycznie w przewidywalnej sekwencji odpowiednie ułożenie plików i brak fragmentacji miało znaczeni kluczowe ponieważ głowica nie wykonywała dalekich skoków które jeszcze wtedy zdarzało się ze były realizowane przez silniki krokowe a nie voice coil. I dwa identyczne komputery były się w stanie uruchamiać z rożną szybkością. Tutaj trzeba się zmierzyć z inną skalą problemu w dosie byłem to w stanie opanować jako uczeń podstawówki. W Windowsie mogło by to być nie trywialne.

 

To będzie dla mnie powielenie tego schematu Bo naprawdę jest wiele zapomnianych rozwiązań które kiedyś były stosowane powszechnie ale poszły w niepamięć.

To umieszczanie w jednym pliku tez kiedyś grali nazywało się to drvspace/dblspace to było narzędzie do kompresji dysków które pozwalało zaoszczędzić miejsce tracone w slackspace przy dużej ilości plików (tak pi razy drzwi 0.5 pojemności pojedynczego sektora/plik) i jeszcze troszkę przez kompresje. Problem jednak jest taki ze taki pojedynczy plik ma ten minus ze musi posiadać dodatkowo jakąś wewnętrzna strukturę. Co daje dodatkowy narzut na jego przeszukiwanie.

Tak i nie. Na tej zasadzie obecnie działa pamięć wirtualna. O tym pisałem a nie o drvspace które służyło do zupełnie innych celów.

Przeliczenie adresów w przypadku takiego pliku to owszem opóźnienie ale niewielkie w porównaniu z zyskiem na braku wykonania dodatkowych ruchów głowicą.

Jak dla mnie to pomysł ten musi oszczędzać czas "mechanicznej pracy" dysku a wiec tak rozmieścić dane na dysku i na tyle mało pofragmentowane by głowica wykonywała jak najmniej przeskoków.

To jest już robione od dawna.

z resztą hibernacja jest fajniejsza bo komputer uruchamia się jakieś 10 sekund.

I myślę że hibernacja to przyszłość uruchamiania. Oczywiście lekko zmodyfikowana.

Boje się ze jednak zamkniecie tego w jednym pliku nie minimalizuje skoków głowicy bo będzie koneczne wyszukiwanie oparciu o jakąś strukturę wewnętrzna. I będzie to zdublowanie tej samej czynności raz na poziomie systemu plików a drugi raz na poziomie pliku. Poza tym to była by już ingerencja w sam system.

To jest już robione od dawna.

Wiem, ze to jest robione od dawna nawet ob bardzo dawna  przykład z początku lat 90tyh podałem w pierwszym poście.

Tylko ze o ile ten proces byłem w stanie przeprowadzić ręcznie pod dosem jako mały gnojek chodzący do podstawówki (sam bym na to pewnie nie wpadł ale miałem w okolicy kliku starszych mistrzów a internetu wtedy nie było, to były czasy w których jak znajomy powiedział w swoim technikum ze będzie składać sobie komputer to odpowiedź kolegów z jego klasy brzmiała a jak ty sobie z tymi wszystkimi kabelkami środku poradzisz a Bajtek po złożeniu komputera zalecał 24 ro godzinne testowanie a i tak czytało się to jak SF).

Dzisiaj w przyadku Windowsa XP ręczna taka optymalizacja jest praktycznie niewykonalna i o ile w przyadku dosa kolejność ładowania pliko była albo stała albo definiowana przez mnie to pod Xp nie mam na to wpływu poza tym każdy Windows będzie inny i być może nawet zmienny w czasie i to tu może być genialność tego pomysłu.

Dzisiaj w przyadku Windowsa XP ręczna taka optymalizacja jest praktycznie niewykonalna i o ile w przyadku dosa kolejność ładowania pliko była albo stała albo definiowana przez mnie to pod Xp nie mam na to wpływu

Nie masz wpływu na kolejność ładowania plików, ale przecież możesz podsunąć Windowsowi potrzebne pliki w odpowiedniej kolejności

Ale nie mam gwarancji ze ta kolejność jest stała w czasie.

Nie masz wpływu na kolejność ładowania plików, ale przecież możesz podsunąć Windowsowi potrzebne pliki w odpowiedniej kolejności

Dla Windows XP takim cudem techniki miał być program bootvis (który w jedynie sobie znany sposób optymalizował proces uruchamiania systemu).

  Odnośnie kolejności uruchamiania programów - w jakimś chipie (z ostatniego pół roku, w dziale jakże pomocnych "tipsów") był opis jak ustalić własną kolejność uruchamiania aplikacji - wszystkie automatycznie uruchamiane programy znajdujące się w najróżniejszych miejscach rejestru są pakowane do pliku wsadowego (BAT), który jest automatycznie uruchamiany (za pośrednictwem rejestru) z systemem. Z tego co mi pozostało w pamięci ręczne przerzucenie wszystkich wpisów w jedno miejsce uruchamiania się nie sprawdza, bo Windows domyślnie uruchamia programy na zasadzie "kto pierwszy ten lepszy". Pomijam fakt że rejestr w Windowsie jest jednym wielkim śmietnikiem, w którym połowa rzeczy nigdy nie powinna się znaleźć.

BTW - co za różnica czy system uruchamia się 2 min czy też 4min? Ważne jest, aby działał szybko już po uruchomieniu. U mnie komputer "chodzi" praktycznie przez cały dzień, tak więc nawet zakładając 3 uruchomienia - 6 - 12 minut wobec 12 godzin jest niczym.

[jak na złość nie znalazłem przycisku umożliwiającego edycję posta]

Ale nie mam gwarancji ze ta kolejność jest stała w czasie.

Nie wiem, jak jest w Windowsie, bo ma zamknięte jądro, ale w Linuksie możesz bardzo precyzyjnie ustalić kolejność wgrywania poszczególnych plików. Spodziewam się, że w Windowsie też.

Sęk w tym, że systemowo praktycznie nie ma sposobu na ustalenie kolejności autostartu, a jedynie włączenie/wyłączenie. W systemach 9x były narzędzia walign/winalign, które optymalizowały aplikacje. Pakiet Nortona także prócz świetnego defragmentatora miał jakiś optymalizer. Pamiętam, że było też narzędzie, które ładowało do pamięci DLL-ki zanim uruchomiono aplikację. Natomiast jedyne sensowne narzędzie do autostartu to Autorun z zestawu dawnego SysInternals i odhaczanie zbędnych programów i "speedlaunch", które rzekomo mają przyspieszyć start niektórych aplikacji (np. acrobar reader czy java quick start), ale przez to zajmują cykle i bieżącą pamięć, zaś samo przyspieszenie jest mało warte. No i oczywiście sensowna defragmentacja. Np. w przypadku O&O Defrag pierw pełna alfabetyczna lub pod względem czasu dostępu, a potem systematyczne defragmentacje wolnego miejsca.

Sęk w tym, że systemowo praktycznie nie ma sposobu na ustalenie kolejności autostartu

Nie, ale jest sposób na ustawienie plików właśnie w takiej kolejności.

Sęk w tym, że systemowo praktycznie nie ma sposobu na ustalenie kolejności autostartu

Ależ oczywiście że jest jak zwykle kilka.

Plik bat z ukrytym wyprowadzaniem wyników na ekran.

Boje się ze jednak zamkniecie tego w jednym pliku nie minimalizuje skoków głowicy bo będzie koneczne wyszukiwanie oparciu o jakąś strukturę wewnętrzna. I będzie to zdublowanie tej samej czynności raz na poziomie systemu plików

Nie trzeba się bać Trzeba ten plik wczytać do dużej pamięci RAM i wówczas można skakać po niej jak się chce. Zresztą podobnie działa pamięć wirtualna o której pisałem wcześniej Obecnie przeciętny nowy komputer ma tej pamięci 2 GB lub więcej, przy czym XP wystarczy 500-600 MB. Resztę można właśnie tak wykorzystać.

No tak, ale to NIE jest rozwiązanie systemowe (udostępniane przez system), a zabawa na około. Zresztą to tylko uszereguje moment uruchomienia zadania i nie spowoduje przyspieszenia ładowania. Pamiętać trzeba także, że same aplikacje też nie startują błyskawicznie, a wpierw przygotowują swoje środowisko, ładują biblioteki itd., zatem multitasking i tak swoje zrobi i ich uruchomienie się nałoży na siebie. No chyba, że da się opóźnienia, ale przecież zależy tutaj na jak najszybszym starcie. Poza tym kolejności/opóźniania uruchamiania serwisów, sterowników itd. w ten sposób się nie zrealizuje, a nie sądzę, by ktoś miał (z ludzi którzy nie moją śmietnika na kompie) z 30 wpisów w autostarcie i HKCU/HKLM\Run, by było to aż takim obciążeniem przy starcie.