Windows 7/2008 R2 kernel újdonságok - Teljesítménynövelés III.

A boot, az altatás és a hibernálás olyan folyamatok, amelyek sose lehetnek elég gyorsak. Mivel ezek nagyon szem előtt vannak, ezért ezek gyorsítására minden Windowsban jelentős erőfeszítéseket tesznek.
 

A Windows 7-ben kifejezetten rámentek az NVRAM-ok, Solid State Diszkek és hibrid merevelemezek erőteljes kiaknázására a boot gyorsítása érdekében. Mivel bekapcsolás után az NVRAM eszközök azonnal üzemkészek, míg a merevlemezeknek kell 2-5 másodperc mire felpörögnek, azért a gép leállítása során a következő boot első fázisához szükséges fájlokat előre berakják egy alkalmas NVRAM eszközbe, így a következő boot során már a merevlemez felpörgése előtt elindul az alapvető komponensek betöltése. Ez már ismerős Vistából, ez volt a ReadyDrive. Ez nyilvánvalóan gyorsítja a boot folyamatát, illetve a hibernálásból visszatérést.
 

Egy másik, igen jelentős módosítás tud még sokat gyorsítani a booton. Ahogy az 1. ábrán látható a jelentős idő megy el az alaplapi és a bővítő portokra felfűzött eszközök felkutatására és a hozzájuk kapcsolódó eszközmeghajtók betöltésére (zöld csík). Ez a folyamat időben sorosan zajlik le Windows 7 előtt, azaz a Windows detektál egy eszközt, majd betölti a meghajtóját, aztán jön a következő, stb.

 1. ábra: boot folyamat Windows 7 előtt

 

Windows 7-ben az eszközök detektálása és a meghajtók betöltése is párhuzamosan történik, ami jelentősen lecsökkenti ennek az idejét (zöld és szürke csík). Emellett az is látható, hogy a Session 0 betöltése párhuzamosan történik az eszközmeghajtók betöltésével, így a user-módú szervizek hamarabb indulhatnak el, és a beléptető képernyő is hamarabb jelenik meg.

2. ábra: boot folyamat Windows 7-ben

 

A registry az egyik leggyakrabban használt erőforrás a Windowsban, hisz ebben van például a COM regisztráció, a filetípus-program hozzárendelések, a szervizek és az eszközmeghajtók konfigja, sok program saját beállításai, a teljesítményszámlálók egyes részei, eventlog regisztrációk, stb., stb. Emiatt a Windows általunk észlelt válaszsebessége alapvetően függ a registry teljesítményétől is. Gondolom ismerős az az tapasztalat, hogy a frissen telepített Windows igen fürge, ám pár havi vagy évnyi használat után meglehetősen lomhává válik. Ennek egyik (számtalan más mellett) oka a behemótra dagadt és belassult registry szokott lenni.
 

A registryt egyszerre nagyon sok szál használja, így az adatok épségét szálak közötti szinkronizációval kell védeni a Windowsnak. Mint a grafikus alrendszer optimalizálásánál láthattuk, ha egy nagy zárolást kicserélnek sok kicsire, akkor egy többszálú rendszer áteresztőképességét nagyban meg lehet növelni. Ugyanezt az elvet használták ki a registry gyorsításánál is.
 

A registry mögött egy 2048 elemből álló hashtábla áll, amely a programok által megnyitott registry elérési utakat jegyzi, hogy ha egyszerre több szál is megnyitja ugyanazt a registry kulcsot, ugyanazt a belső kezelőszámot kapja meg, hogy az adatmódosításokat tudja szinkronizálni a Windows. A hashtábla minden registry ágat egységesen kezeli, azaz ugyanabban a hash bugyorban lehet egy HKLM kulcs és bármely felhasználó saját kulcsa is (KHCU). Mivel minden egyes hash láncolathoz egyszerre csak 1 szál férhet hozzá, azaz szinkronizált a hozzáférés, ezért egy pl. HKCU-n végzett művelet feltarthat pl. egy HKLM-en végzett más műveletet, azaz torlódhatnak a szálak.
 

Windows 7/2008R2-től kezdve minden ág (hive, mint a HKLM) saját szinkronizált hash struktúrát kapott, így az ágak közötti zárolások már nem okoznak problémát. Persze ez nem oldja meg az egy ágon belüli torlódást, de legalább a szervizek által gyakran használt HKLM és a felhasználói adatokat tároló HKCU-k nem akadnak össze.
 

Másik elv, ami miatt gyorsabb lesz a registry kezelés, az a memóriára leképezés módosítása. Eddig Memory Mapped View-ként (ld. a Windows memóriakezelése c. cikk 2. részét, http://www.microsoft.com/hun/technet/article/?id=d0da1b41-169a-4e8c-a793-d0af5dc31d37) töltötték be, ami miatt memóriakényszer esetén sokszor kellett bemapelni és unmapelni a registry bizonyos részeit, pont akkor, amikor már eleve lassú a gép a memóriakényszer okozta lapozás miatt.
 

Mostantól a Paged Poolba (http://www.microsoft.com/hun/technet/article/?id=d698795b-d9a0-4c78-bd65-3be12d0780dc) olvassa be a Windows a registryt, így nem kell mapeléssel időt tölteni, az közvetlenül a programok rendelkezésére áll.
 

A 64 bites Windowsok szinte minden szempontból kompatibilis módon tudják futtatni a 32 bites alkalmazásokat. Ennek sok lába van, az egyik a registry nézetek biztosítása a 32 és a 64 bites alkalmazások részére. Könnyű belátni, hogy pl. az in-process COM regisztrációkat nem lehet keverni a két platform között, mert egy 64 bites folyamat (közvetlenül) nem tud betölteni egy 32 bites in-process COM DLL-t.
 

Viszont mind a 32 bites, mind a 64 bites programok is a HKLM\Software\Classes alatt keresik a COM komponenseket, így nyilvánvaló, hogy a Windowsnak mindkét oldal részére egy csak a számára látható nézetet kell biztosítani. Erre találták ki a registry redirectiont. Pl. 32 bites programok a HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node mögötti tartalmat látják, amikor a HKEY_LOCAL_MACHINE\SOFTWARE-re hivatkoznak.
 

Vannak viszont EXE-ként megvalósított COM komponensek, amelyek 32 és 64 bites folyamatok között is működnek, mivel két külön folyamatban fut a hívó és a hívott komponens. Ebben az esetben, ha mondjuk egy 64 bites COM komponens beregisztrálja magát a 64 bites ágba, azt a 32 bites hívóknak is látnia kell. Erre szolgál a registry reflection nevű technológia. Ha egy 32 bites program regisztrál egy 32 bites COM komponenst, akkor azt a Windows átmásolja a 64 bites részbe is, hogy mindkét oldal hívhassa a komponenst. Vagy mondjuk, egy program beregisztrálja, hogy ő kezeli a .alma kiterjesztésű fájlokat, ezt látni kell mindkét oldalnak, azért az egyik oldalra bemásolt információt a registry reflector átmásolja a mások bitű oldalra. Elképzelhetjük, hogy ez jól megnyomja a registry méretét.
 

Windows 7/2008R2-től kezdve a registry redirection úgy változik, hogy csak azokat az al-kulcsokat osztja és másolja ketté a Windows, amit tényleg két oldalról is használnak, és nem duplikálja kapásból az egész SOFTWARE kulcsot, hanem megosztja a két oldal között, ezzel sokkal kevesebb lesz a közös registry mérete.
 

Másfelől a reflectiont teljesen kidobták, a Windows nem szinkronizálja a két ág COM adatait, ezzel a felére csökken a registry mérete a COM ágat tekintve. Mivel ez csak a COM komponenseket érintette és a változást a Windows belül lekezeli, így a külvilág számára ez a változás nem érzékelhető, csak az, hogy sokkal kisebb lett a registry, és gyorsabb a Windows.