數據預讀機制
微軟採用的一種全新系統後台數據預讀機制，它可以提高系統性能，加快Windows XP/2003的啟動速度，經過預讀的程式全部存放在系統所在資料夾下的prefetcher目錄中（圖1），檔案名稱格式類似於下面這個樣子： foxmail.exe-2B721FDE.pf（這是Foxmail的預讀檔案）。Windows XP/2003雖然採用了預讀取機制，但是默認設定下比較保守，我們可以自己來定義程式的預讀取方式，大幅度提高系統的性能。常見問題
在使用Windows XP較長時間後，我們會發現系統運行速度明顯慢了下來，用多最佳化軟體、卸載已經安裝的軟體都解決不了問題。究竟為什麼呢？原來罪魁禍首就是預讀設定。在 “Windows＼Prefetch”資料夾面有很多個以PF為擴展名的檔案，這就是預讀檔案，如果將裡面的檔案清空以後，你就會發現系統運行速度又恢復正常了！看來，預讀設定可以提高系統速度，但是使用一段時間後，預讀檔案夾里的檔案又會變得很多了，導致系統搜尋花費的時間變得很長。而且有些應用程式會產生死連結檔案，進而加重了系統搜尋的負擔。解決辦法
因此，我們應該定期刪除這些預讀檔案，用以提高開機速度。當然，Windows XP重新設定預讀對象是允許的。具體方法是：打開註冊表編輯器，依次展開HKEY_LOCAL_MACHINE＼SYSTEM＼ CurrentControlSet＼Control＼Session Manager＼Memory Management＼PrefetchParameters分支，在右側視窗中雙擊“EnablePrefetcher”，在打開的“DWORD”值編輯視窗中，可以對Windows XP進行預讀設定：
將該值設定為“0”，即為取消預讀功能；設定為“1”，系統將只預讀應用程式；設定為“2”，系統將只預讀Windows系統檔案；設定為 “3”，系統將預讀Windows系統檔案和應用程式。一般我們將該值設定為“2”即可，當然，如果你的計算機配置很高，如使用PIII 800MHz CPU以上的建議將數值數據更改為4或5，也可以保留數值數據為默認值即3。這樣可以加快系統運行速度。
prefetch，預存取，這在vista用戶可能知道的多些，其實xp下就有這一技術了，只是官方少有這方面介紹，更別提技術文檔了。 這是xp一個隱藏的特性，用處是在xp登錄進度條出現時，就把c:\windows\prefetch目錄下的*.pf檔案信息預先裝載到記憶體中，以便於提高系統性能。這些*.pf檔案是系統和應用程式啟動時留下的預存取檔案，描述了系統和應用程式每次啟動時裝載模組的信息和順序，並且其命名方式中包含一個描述其完整路徑的十六進制值。
另外，prefetch目錄中還有一個重要檔案，就是layout.ini這個磁碟布局初始化檔案，它記錄了所有預存取程式及檔案的載入信息和順序（按優先權排列），這也為這些程式檔案的磁碟分配提供了最最佳化方案的依據。
局部碎片整理
說到這，不得不提一下“局部碎片整理”，按照官方所說，xp每隔3天就會自動進行一次局部碎片整理，我發現這個整理動作是分步實施的，而且是在系統空閒時才會運行，這多虧了剛裝上的SSM截獲了defrag的這個動作信息，連命令行參數都一併截獲，這個重點留待稍後再說。（其實系統在啟動時也可以進行局部碎片整理，使得啟動時需要的檔案能夠被整理到相鄰位置，這個功能可以在註冊表中開啟，HKLM\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunetion下enable鍵由默認的N改為Y即可）用Filemon跟蹤發現，系統進行局部碎片整理時，先讀取layout.ini檔案，然後調用defrag針對layout.ini中涉及的檔案進行整理，然後把轉移信息再寫入到layout.ini中，這個自動整理不同於server2003系統的自動碎片整理功能（Auto Defragmenter）。開啟預存取
至於是否開啟預存取，有不少爭論，但是我堅決認為應該開啟，否則系統速度會變得更慢。HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters目錄下，EnablePrefeteher子鍵的值決定以何種方式開啟prefetch，0取消，1隻預存取應用程式，2隻預存取windows系統檔案，3同時存取系統和應用程式檔案，xp默認情況下是3。以上這些prefetch相關功能依賴於task schedule計畫任務這項服務。defrag的參數
現在該說那個重點了，系統自動調用的defrag的參數是什麼？是-p -s和-b。-p後面跟著一個常量，例如5E4；-s後也跟一個常量，比如000018A4；-b後跟著盤符C：，那么這個命令行的例子就是：defrag.exe -p 5E4 -s 000018A4 -b C: 了。-b這個參數網上一直有傳言，說是defrag的隱藏參數，但是官方不給出澄清，我也不知道是否真的存在，這回算是證實了。-b C:就是對預存取的檔案進行局部整理，並且每次僅針對一個pf檔案相關程式檔案進行整理，-p和-s應該就是用來選擇哪一個pf的，但具體那兩個常量和被選pf檔案有什麼聯繫，還有待進一步分析。平時如果想對系統和應用程式檔案進行一次最佳化碎片整理，可以在命令行中敲入defrag.exe C: -b，這樣會對所有prefetch檔案進行整理，完成後你會覺得系統的速度有一定提升。經驗談
經驗之談，如果不小心刪除了prefetch目錄下的檔案，尤其是layout.ini檔案，如何重建？敲入rundll32.exe advapi32.dll,ProcessIdleTasks命令，然後重啟三次系統，就可以重建layout.ini檔案，為什麼是三次，我也不知道，大概和每隔三天整理一次有關係吧。windowsxp開機有一個進度條，會一遍一遍的跑，不少人認為只跑兩圈就進去的就是開機速度快
網上出現過一種最佳化方式，修改註冊表將所謂的“開機預讀取”設定為“不預讀”，則可以大大減少進度條“跑”的次數，但是這種“最佳化方法”出來不久，便有更多的文章指出這是“謬誤”，還舉出相當多的事例，或是試驗，說明不預讀並不能減少開機時間，大多的理由是進度條消失後的“黑屏時間”增加。
因為一直用的休眠，所以我一直也沒怎么在意。前兩天和別人談到這個問題，我便好好研究一番。
結論是，其實關於這個問題，所謂設定為“不預讀”的最佳化方法也並非謬誤，而這個所謂的預讀也並非沒有用處，否則MS怎么也不會花人力物力弄這么個浪費開機時間的東西。
先說說什麼是所謂的“預讀取”。預讀取分兩種，一種是“系統檔案預讀”，一種是“應用程式預讀”。具體的不去討論，現在只討論預讀取對速度的影響。
我們都有經驗，當第一次打開word的時候會等待比較長的時間，硬碟燈不停的在亮，但是關閉再次打開，word啟動速度就快得多了。這個其實就是windows的預讀取做的最佳化。windows預讀取發現你帶開了一個他的預讀取資料庫沒有的應用程式時，他就會將這個應用程式中某些信息在記憶體中留下一個映象，下次打開這個程式就不用再去硬碟上找檔案，能大大加塊程式啟動速度。
問題來了，記憶體中的映象重新啟動之後就會消失，下次開機啟動程式依然很慢，怎么辦呢？這就需要“開機預讀取”功能。Windows會把使用頻率較高的一些應用程式的信息記錄下來，每次開機時，就完成一次對程式的預讀取，從而大大加快應用程式的啟動速度。
你大概已經猜到，那個“進度條”一遍一遍的跑的時候，windows就在進行開機預讀取的工作。
因此，如果直接取消掉註冊表中的“預讀取功能”是一定會大大降低應用程式的啟動速度的，當然開機速度會有一定的增加，不過這是得不償失，因為沒有了那一段必要的“系統檔案預讀取”，在進度條消失之後系統會從硬碟上去尋找大量的系統檔案，反而影響啟動速度，而且應用程式的啟動速度也是一定會大大減慢的。其實比較好的最佳化辦法是這樣，找到“開機預讀取”的信息，手動把不是很常用，不需要預讀取的應用程式刪除，儘量減少開機預讀取的應用程式的數量，由此來加快啟動速度！
位置在x:\windows\prefetch下面，命名是 exe檔案名稱-16進制hash.exe
有一些實測數據，一台裝了許多套用軟體的電腦：
不作處理，開機29s,取消預讀取，開機32s，刪除prefetch資料夾下面大部分檔案後，開機23s,有比較明顯的開機速度提升，不過第一次運行應用程式的時候速度的確有所下降，並且prefetch資料夾下檔案會自動生成，越來越多！
其中最“有效”的一個檔案是NTOSBOOT-B00DFAAD.pf，它可以大大提高Windows的啟動速度。如果只求啟動速度的話，可以只保留這個檔案和Layout.ini，然後將Task Scheduler服務設為手動。
當然，要想真正看到預讀效果，必須保證開機後記憶體占用小於物理記憶體量。（比如：開機後從任務管理器看出記憶體占用是480MB，而你的物理記憶體是256MB的，那么就幾乎看不到預讀的效果。）
MS網站上對prefetch的解釋
PrefetchAll versions of Windows except real-mode Windows 3x are demand-paged operating systems, where file data and code is faulted into memory from disk as an application attempts to access it. Data and code is faulted in page-granular chunks where a page's size is dictated by the CPU's memory management hardware. A page is 4KB on the x86. Prefetching is the process of bringing data and code pages into memory from disk before it's demanded.
In order to know what it should prefetch, the Windows XP Cache Manager monitors the page faults, both those that require that data be read from disk (hard faults) and those that simply require that data already in memory be added to a process's working set (soft faults), that occur during the boot process and application startup. By default it traces through the first two minutes of the boot process, 60 seconds following the time when all Win32 services have finished initializing, or 30 seconds following the start of the user's shell (typically Microsoft Internet Explorer), whichever of these three events occurs first. The Cache Manager also monitors the first 10 seconds of application startup. After collecting a trace that's organized into faults taken on the NTFS Master File Table (MFT) metadata file (if the application accesses files or directories on NTFS volumes), the files referenced, and the directories referenced, it notifies the prefetch component of the Task Scheduler by signaling a named event object.
The Task Scheduler then performs a call to the internal NtQuerySystemInformation system call requesting the trace data. After performing post-processing on the trace data, the Task Scheduler writes it out to a file in the \Windows\Prefetch folder. The file's name is the name of the application to which the trace applies followed by a dash and the hexadecimal representation of a hash of the file's path. The file has a .pf extension, so an example would be NOTEPAD.EXE-AF43252301.PF.
An exception to the file name rule is the file that stores the boot's trace, which is always named NTOSBOOT-B00DFAAD.PF (a convolution of the hexadecimal-compatible word BAADF00D, which programmers often use to represent uninitialized data). Only after the Cache Manager has finished the boot trace (the time of which was defined earlier) does it collect page fault information for specific applications.
這個似乎是最影響啟動速度的檔案，也就是所謂的“系統檔案預讀取”吧
When the system boots or an application starts, the Cache Manager is called to give it an opportunity to perform prefetching. The Cache Manager looks in the prefetch directory to see if a trace file exists for the prefetch scenario in question. If it does, the Cache Manager calls NTFS to prefetch any MFT metadata file references, reads in the contents of each of the directories referenced, and finally opens each file referenced. It then calls the Memory Manager to read in any data and code specified in the trace that's not already in memory. The Memory Manager initiates all of the reads asynchronously and then waits for them to complete before letting an application's startup continue.
How does this scheme provide a performance benefit? The answer lies in the fact that during typical system boot or application startup, the order of faults is such that some pages are brought in from one part of a file, then from another part of the same file, then pages are read from a different file, then perhaps from a directory, and so on. This jumping around results in moving the heads around on the disk. Microsoft has learned through analysis that this slows boot and application startup times. By prefetching data from a file or directory all at once before accessing another one, this scattered seeking for data on the disk is greatly reduced or eliminated, thus improving the overall time for system and application startup.
Figure 1 Prefetch Directory
To minimize seeking even further, every three days or so, during system idle periods, the Task Scheduler organizes a list of files and directories in the order that they are referenced during a boot or application start, and stores the list in a file named \Windows\Prefech\Layout.ini. Figure 1 shows the contents of a prefetch directory, highlighting the layout file. Then it launches the system defragmenter with a command-line option that tells the defragmenter to defragment based on the contents of the file instead of performing a full defrag. The defragmenter finds a contiguous area on each volume large enough to hold all the listed files and directories that reside on that volume and then moves them in their entirety into that area so that they are stored one after the other. Thus, future prefetch operations will even be more efficient because all the data to be read in is now stored physically on the disk in the order it will be read. Since the number of files defragmented for prefetching is usually only in the hundreds, this defragmentation is much faster than full defragmentations.
