Chinaunix首页 | 论坛 | 博客
  • 博客访问: 3133919
  • 博文数量: 117
  • 博客积分: 10003
  • 博客等级: 上将
  • 技术积分: 5405
  • 用 户 组: 普通用户
  • 注册时间: 2007-01-23 09:34
文章分类

全部博文(117)

文章存档

2011年(1)

2010年(10)

2009年(69)

2008年(37)

分类: LINUX

2009-03-09 22:45:36

偶然跟同事谈起WINDOWS下的预读取功能.平时很少在意这个,只有个大概的了解.刚才在MS官方站点找到点说明.
Quote
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 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.
  记得以前总有人这么认为,开机时候的进度条,跑的圈数少,就是开机速度快.也有修改注册表将Prefetch关闭,减少进度条滚动次数的"优化".我的感觉是,既然存在,就有其价值.MS的每个细节都有自己的意义.

   Prefetch里面分OS FILE和APP FILE,里面具体的我没研究过.但我直观的感觉很明确,当我第一次打开VS.NET的时候会等待比较长的时间,硬盘不停的在读取数据.关闭以后再打开 VS.NET,启动速度快了很多.这也就是Prefetch做的优化.OS侦测到用户打开了一个Prefetch数据库没有的APP时,就会将此APP中 某些信息在内存中留下一个映象,下次打开这个APP就不用再去硬盘上找文件,从而加块APP启动速度.

  内存中的映象Reset之后会消失,下次开机启动APP依然很慢,从而Prefetch发挥了作用.OS把使用频率高的APP信息记录下来,每次开机就完成一次对程序的预读取,从而加快APP的启动速度.开机时的滚动条应该就是OS在进行开机预读取的工作.

   如果直接取消掉注册表中的Prefetch肯定降低APP的启动速度,但开机速度会有增加,可是得不偿失,没有了Prefetch,滚动条消失以 后,OS得从硬盘上寻找所需文件,反而影响速度.而且APP的启动速度绝对比以前慢.但Prefetch文件夹里的文件肯定是不断增加,过多会影响启动速 度.最好的办法是把其中常用的保留,其他的删除掉.Prefetch下面文件的命名方式是EXE文件名-16进制hash.exe
阅读(1265) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~