windowsxp开机有一个进度条，会一遍一遍的跑，不少人认为只跑两圈就进去的就是开机速度快

网上出现过一种优化方式，修改注册表将所谓的“开机预读取”设置为“不预读”，则可以大大减少进度条“跑”的次数，但是这种“优化方法”出来不久，便有更多的文章指出这是“谬误”，还举出相当多的事例，或是试验，说明不预读并不能减少开机时间，大多的理由是进度条消失后的“黑屏时间”增加。

因为一直用的休眠，所以我一直也没怎么在意。前两天和别人谈到这个问题，我便好好研究一番。

结论是，其实关于这个问题，所谓设置为“不预读”的优化方法也并非谬误，而这个所谓的预读也并非没有用处，否则ms怎么也不会花人力物力弄这么个浪费开机时间的东西。

先说说什么是所谓的“预读取”。预读取分两种，一种是“系统文件预读”，一种是“应用程序预读”。具体的不去讨论，现在只讨论预读取对速度的影响。

我们都有经验，当第一次打开word的时候会等待比较长的时间，硬盘灯不停的在亮，但是关闭再次打开，word启动速度就快得多了。这个其实就是windows的预读取做的优化。windows预读取发现你带开了一个他的预读取数据库没有的应用程序时，他就会将这个应用程序中某些信息在内存中留下一个映象，下次打开这个程序就不用再去硬盘上找文件，能大大加块程序启动速度。

问题来了，内存中的映象重新启动之后就会消失，下次开机启动程序依然很慢，怎么办呢？这就需要“开机预读取”功能。windows会把使用频率较高的一些应用程序的信息记录下来，每次开机时，就完成一次对程序的预读取，从而大大加快应用程序的启动速度。

你大概已经猜到，那个“进度条”一遍一遍的跑的时候，windows就在进行开机预读取的工作。

因此，如果直接取消掉注册表中的“预读取功能”是一定会大大降低应用程序的启动速度的，当然开机速度会有一定的增加，不过这是得不偿失，因为没有了那一段必要的“系统文件预读取”，在进度条消失之后系统会从硬盘上去寻找大量的系统文件，反而影响启动速度，而且应用程序的启动速度也是一定会大大减慢的。其实比较好的优化办法是这样，找到“开机预读取”的信息，手动把不是很常用，不需要预读取的应用程序删除，尽量减少开机预读取的应用程序的数量，由此来加快启动速度！

位置在x:\windows\prefetch下面，命名是     exe文件名-16进制hash.exe

有一些实测数据，一台装了许多应用软件的电脑：

不作处理，开机29s,取消预读取，开机32s，删除prefetch文件夹下面大部分文件后，开机23s,有比较明显的开机速度提升，不过第一次运行应用程序的时候速度的确有所下降，并且prefetch文件夹下文件会自动生成，越来越多！

下面是ms网站上对prefetch的解释

prefetch
all 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 pages size is dictated by the cpus 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 its 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 processs 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 users 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 thats 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 files 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 files 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 boots 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 thats not already in memory. the memory manager initiates all of the reads asynchronously and then waits for them to complete before letting an applications 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.