Yet another Web site posted yet another “tip” today recommending that you clean out your Prefetch folder to improve performance of Windows. Arrrggghhh! I’ve written about this repeatedly (here and here and here, for instance), but the message doesn’t seem to be spreading very fast. Maybe this quote from “Misinformation and the Prefetch Flag” by Ryan Myers, a developer on Microsoft’s Windows Client Performance Team, will help:
XP systems have a Prefetch directory underneath the windows root directory, full of .pf files — these are lists of pages to load. The file names are generated from hashing the EXE to load — whenever you load the EXE, we hash, see if there’s a matching (exename)-(hash).pf file in the prefetch directory, and if so we load those pages. (If it doesn’t exist, we track what pages it loads, create that file, and pick a handful of them to save to it.) So, first off, it is a bad idea to periodically clean out that folder as some tech sites suggest. For one thing, XP will just re-create that data anyways; secondly, it trims the files anyways if there’s ever more than 128 of them so that it doesn’t needlessly consume space. So not only is deleting the directory totally unnecessary, but you’re also putting a temporary dent in your PC’s performance. [emphasis in original]
Bottom line: You will not improve Windows performance by cleaning out the Prefetch folder. You will, in fact, degrade Windows performance by cleaning out the Prefetch folder. I’ve done performance testing that establishes this definitively. In all the many sites that offer this bogus tip, I have yet to see a single piece of actual performance testing.
Oh, and for anyone who cites this TechRepublic article as a source, let me just say that it contains more serious factual errors than I can count. For instance:
As you boot your workstation or access programs on your workstation, XP’s prefetcher copies portions of those files to the Prefetch area of your hard drive.
That’s completely wrong. The files in the Prefetch folder contain lists of pages that that should be loaded when a program starts. Each file is essentially an index. Windows XP doesn’t copy portions of any files to the Prefetch folder.
When your workstation boots, XP prefetches portions of the files you use most frequently and has any application you’ve recently run waiting and ready to go.
This is equally absurd. If this were true, it would mean that Windows was actually loading into memory every program you’ve ever used, every time you start Windows. That’s not the way it works at all. When your PC starts up, Windows looks in the Prefetch folder to determine how best to load Windows. It doesn’t do a thing with the .pf files for applications (unless, of course, you’ve configured one of those apps to start up with Windows).
If you’re frequently using the same few applications over and over again, prefetching can greatly increase the apparent speed of a system. Rather than waiting for you to click an icon to start a program, and then loading all of the associated files, libraries, and pointers necessary to run the program, XP has all the components of your programs preloaded. When you click an icon to start the program, most of the hard work is already done.
The author just made this up. The .pf files don’t get used at all until you run a program. What actually happens when you click an icon is that Windows uses the information in the Prefetch folder to decide which program segments to load and in what order to load those pages. There’s plenty of documentation for this, including Ryan Myers’ article and this definitive article by Mark Russinovitch and David Solomon, Windows XP Kernel Improvements Create a More Robust, Powerful, and Scalable OS.
The drawback to prefetching is that XP will prefetch a program even if you use it only once or twice. XP will retain a copy of a portion of it in the Prefetch folder. From there, it will prefetch the program, taking resources from your workstation even though you may have no intention of ever using the program again.
Again, the author just pulled this out of who-knows-where. When you run a program, Windows creates a .pf file for it in the Prefetch folder. When you run the program again, Windows looks for this .pf file and uses it to determine how to load the program. The hash doesn’t contain any portion of the original program code. If you never run the program again, that .pf file never gets used, and in fact it gets deleted eventually.
I used to write for TechRepublic. I’ve tried to contact someone there to get them to correct this silly article but have yet to receive a response. It would be really, really great if some of the other sites that have propagated this urban legend would also correct it.
Canli,
What do you mean they are “compressed”? How do you know this?
Luis, If those files had an extension .pf than they are NOT a Virus. Many AntiVirus and AntiSpyware apps incorrectly identify the associated Prefetch file that was linked to an infected executable as a Virus or Malware. If the extension was .pf for those files then I suggest you report the false positive (this is common). Prefetch files are NOT EXECUTABLE!!!
LD, can you point to any published tests that use proper controls and show performance benefits from cleaning the Prefetch folder?
Andrew, clearly you did not read my post properly. I followed “correct” procedure (as you stated) and confirmed that prefetching was working.
1) I am not using nLite. Not sure how you came to that conclusion. In fact about the only tweaks I use are with MS’s own TweakUI application(s) and shutting off a handful of services (no more than five of them).
2) Like I said, I followed the procedure as prescribed by you. I checked the “EnablePrefetcher” registry setting as well and it was set to “3″
3) Once again, I did follow that procedure and CONFIRMED that prefetching was working. The time taken since that last post has also demonstrated that to me. On a side note, you should know as well as the next person that Windows’ Disk Defragmenter software is next to useless.
Like I said in my original post, I timed the procedure from the moment I pushed the power button to the disappearance of userinit.exe. That’s a whole lot more accurate than just timing “until startup”.
userinit.exe:
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/12330.mspx?mfr=true
Now, since my last post i have installed/removed some programs. I decided to defragment my hard drive (including MFT) with Raxco PerfectDisk and run some more tests – with Prefetching ON. After doing this, the load times for those apps were as follows:
28, 16, 10, 4, 4, 4, 4
The Windows boot time was 75 seconds.
I then disabled prefetching using the method you described. The results are as follows:
28, 16, 10, 4, 4, 4, 4
The system boot time was 73 seconds.
Note that the boot time was 2 seconds less and that once again, there were no changes to the application load times. You might have noticed a drop in the application load times for the first three apps. This is largely attributable to defragmenting the Master File Table (MFT). Note that XP’s Disk Defragmenter is incapable of defragmenting the MFT metadata, which really is a contradiction of terms given that the MFT metadata contains the info on file locations and fragments (if the drive is fragmented) and XP is happy to leave the MFT metadata horribly fragmented… *sigh*
I stand by what I said. Disabling prefetching is over-rated and enabling prefetching is over-rated (for me), however results can vary from one PC to the next. There are other things users can (safely) do to achieve greater results.
Sorry 50 but you did something wrong. I have seen this many times. You are not documenting your testing procedures which are obviously flawed since your system is taking 75 seconds to bootup. How old is your system? Because I have various test systems at my shop and my ancient 7 year old PIII 1GHZ, 512MB, 60GB 7200RPM HD box boots in 56 seconds with Prefetching working properly. I suggest listing your complete system specs and your exact testing procedures. Because something is seriously wrong.
For boot timing the following must be followed:
YOU CANNOT SKIP THESE STEPS:
1. The Task Scheduler must be set to automatic and confirmed running.
2. The EnablePrefetcher Registry value must be set to 3.
3. REBOOT Windows and after the desktop is finished loading WAIT 2 full minutes so that the NTOSBOOT-B00DFAAD.PF can be built properly and then check that it is in the Prefetch folder and has a modified date and time from today.
4. REBOOT A SECOND TIME and after the desktop is finished loading WAIT 2 full minutes
5. ONLY after waiting the full 2 minutes on the SECOND boot then Go to “Start”, “Run”, Type Rundll32.exe advapi32.dll,ProcessIdleTasks. This can take 10-15 minutes to run but no notification will be given when it is finished. You will notice increased Harddrive activity while it is running wait until this stops. When this is finished in the “Run” box Type defrag c: -b and again wait for the HD activity to stop. This is necessary to confirm the idle tasks were run.
STEP 5 does not CONFIRM prefetching is running it further optimizes the prefetch files and then lays them out to the HD.
6. Now shut off the computer and time from pressing the power button until the desktop loads. If Bootvis works on your machine it is the most accurate way to time the bootup.
If you were timing the first time after PROPERLY enabling prefeching your results will be WRONG! Because it builds the NTOSBOOT-B00DFAAD.PF for the first two boots after it is enabled. Only on the THIRD boot can your time for Prefetching!!!!
STOP GUESSING. If you do not understand how something works you cannot properly time it!!
Just because my system takes about 75 seconds to boot does not indicate a problem with my PC. What a ridiculous assumption. You fail to take into account POST and any Legacy hardware the PC may be initialising prior to the point that the OS starts loading. Furthermore, you fail to recognise any user software that loaded along with Windows. My PC is initialising two RAID controllers before Windows even starts to load. Both a software firewall and antivirus software are also loaded. These incur a heavy load on any operating system drive. The only other “user” software it visibly loads is the Creative Suite and NVIDIA display suite. The drive is a 36GB 10,000RPM drive. I’d lay down good money that the same Windows config wouldn’t come within 20 seconds of that on a 7200RPM drive.
Secondly, you seem to be under the impression that BootVIS starts timing from power on – a common claim on the internet. It can only start timing after Legacy device initialisation and POST.
I have once again followed your procedure to a tee and once again received the same results on my rig. To appease you I have some machines in my shop also one of which has a fresh install of XP SP2, drivers and nothing else – no tweaks. Nothing. It’s a p4 2.8GHz, 512MB RAM, 40GB 7200RPM HDD.
I timed bootup with that. 76 seconds with a stopwatch. Bear in mind that prefetching was on.
I optimised the system according to step 5 and 6 of your list. Rebooted three times and checked the boot time. 75 seconds.
Next I disabled Task Scheduler and emptied the Prefetch folder. 72 seconds. Now why is that? The system definitely had prefetching working. I guess Windows install much have been botched or maybe faulty hardware? No. This is a seperate PC that’s literally a virgin. It’s never had prefetching disabled and it yields similar results when prefetching is turned off.
You’ve consistently claimed that something is wrong or something to the effect that my PC is going into meltdown or that I’m guessing. Read my posts again. I’ve never set out to prove anything. Just relaying my experiences and once again I have reached the same conclusion I came to in my first post. If you’re so adamant that enabling prefetching is such a great thing, YOU should be the one proving it to us. Show us the differences with it on and off. Until I see your proof, I call your BS claims and raise you one:
If I follow your procedure again and re-enable prefetching, this should “improve system start up times anywhere from 50 – 100%” (to quote your own words)? Maybe that’s taking your words out of context, but I’m sure that most users here won’t be seeing benefits anywhere near as great as you claim let alone seeing benefits at all. That’s not to say nobody will see the benefits but if you saw THAT much improvement, I’d have to say it was YOUR own PC that had serious issues to begin with.
EOT
Like I said something is seriously wrong with your testing or Windows installation.
Computer #1:
P3 1GHz
512MB RAM
60 GB 7200 RPM HD
ZoneAlarm Security Suite (Firewall + AV + AntiSpyware)
With Prefetching enabled = 56 seconds
With Prefetching disabled = 85 seconds
Computer #2
P4 1.8GHz
512MB RAM
60 GB HD 7200 RPM
Windows XP Firewall + Avast AV
With Prefetching enabled = 45 seconds
With Prefetching disabled = 62 seconds
Computer #3
P4 3.0GHz
1GB RAM
36 GB 10,000 RPM Raptor
Mainboard RAID controller present
ZoneAlarm Security Suite (Firewall + AV + AntiSpyware)
With Prefetching enabled = 32 seconds
With Prefetching disabled = 44 seconds
I have proved it on every machine I tested. Since I don’t have your PC in front of me I can not see what is wrong or you are doing wrong.
Obviously Bootvis cannot time your BIOS initialization which is why it is more accurate since it simply isolates the Windows portion of your boot time. Any timing variables due to your Mainboard’s BIOS will produce inconsistent results. BIOS options like auto detect drives or improper boot order such as you CD-ROM before your HD can screw up boot timing testing and lead to inaccurate and inconsistent results.
I have worked on thousands of machines and every single one of them running Windows XP, regardless of configuration has positively benefitted from Prefetching.
Measuring Boot Time
From an end-user perspective, what is important to measure is the time from the moment the power switch is depressed to the time the desktop accepts user input.
AHAH! No mention is made of waiting for USERINIT to unload. Like I said you are IMPROPERLY timing it. This is the advice from the Windows Client Performance Team who’s advice is more accurate than yours. Funny how you just decided to create your own testing procedures without understanding how it even works.
In order to correlate more meaningful numbers with the Windows product team, cold boot time is divided into three phases:
1. BIOS POST. The time for the POST to run and spin up the hard disk drive and for the reading of the operating system boot loader. This ends with the display of the boot menu in the boot loader.
2. Pre-Logon. The time from the boot menu to the Windows Logon screen.
3. Post-Logon. The time from clicking on an account in the Logon screen to the Windows Desktop. This measurement is helpful in assessing delays introduced by items in the Startup group, Run key, and so on.
To measure boot time:
1. Time from pressing the power switch to the display of the boot menu from the boot loader. Log this time as POST.
2. Time from the boot menu to the display of the welcome logon screen user accounts. Log this time as Pre-Log.
3. Time from clicking on a user account to the display of the desktop icons. Log this time as Post-Log.
4. The sum of the times from steps 2–4 is the total boot time.
In working with the Windows product team, it is important to report all three numbers. Wherever a problem is suspected due to resulting times, use the Bootvis.exe tool to get a trace of boot. When taking traces, ensure the system auto-logs on by deleting any extra user accounts. There should be only one user account in addition to the guest account for auto-logon to occur.
Because the number of platters in a disk drive, the memory type, and other factors effect POST time, it helps to isolate these factors away from operating system time by breaking into three numbers. Driver issues tend to show in the pre-log number. Value added software issues normally show during post-log.
Tips:
- Use a single disk partition.
- Use NTFS on hard disk drives. The FAT on FAT32 file systems get large on partitions larger than 8 GB because the whole FAT is read during boot.
- Be sure to allow the disk to fully spin down between measurements. A delay of 20secs is recommended before booting again.
- Make sure you have fully booted the operating system and performed a typical shutdown before timing POST on a system where the BIOS implements the Simple Boot Flag specification. The BIOS implementation of the Simple Boot Flag specification may interpret a shut down from the boot menu as a failed boot, affecting subsequent BIOS POST timing.
- To avoid external network boot delays, unplug network cables. If boot times increase when cables are unplugged, look at the media-sense support in the network adapter and its driver.
You haven’t proven anything. You’ve claimed results with no verification.
“BIOS options like auto detect drives or improper boot order such as you CD-ROM before your HD can screw up boot timing testing and lead to inaccurate and inconsistent results.”
Can but usually don’t unless there is a change in hardware configuration or addition/removal/change of removable media. Don’t forget to mention the variation incurred through human response time on a stop watch.
“From an end-user perspective, what is important to measure is the time from the moment the power switch is depressed to the time the desktop accepts user input.”
This is also taken from the article you quoted.
For the benefit of other readers:
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/Fast%20System%20Startup%20for%20PCs%20Running%20Windows.doc
I have been doing exactly this.
“No mention is made of waiting for USERINIT to unload.”
*sigh* Again you fail to read my posts properly and again you make assumptions.
There is enough info here for people to check for themselves and validate or rebuke your claims.
If you have the Boot sequence setup wrong and have a CD in the drive that is non bootable the CD-ROM can try to access that disk before booting to the C: drive erratically. The variation in human response time is less than a second and with even the smallest noticeable measurable gains due to prefetching on the highest end systems you can still easily time it.
I have already documented on how to properly test this extensively. I have provided links on how to read about how this actually works.
Please link to me the Microsoft documentation that says the boot is complete when the userinit disappears from the task manager. I read you posts maybe you should go reread them. It clearly says:
“to the time the desktop accepts user input”
You are misinforming and misleading others on how to test this.
I suggest you document your testing like the Microsoft Fast Boot Article states and follow their advice to the letter and then contact the Microsoft Performance Team so they can figure out what you are doing wrong since you are so obsessed you are not. The only way for me to prove otherwise would be for myself to personally test your machines. Either that or you are lying. I have tested far to many machines in all sorts of states. I have seen ones that initially saw no gain because Prefetching was broken in some way. In one instance the user was not using an official Microsoft Windows XP CD, it was hacked apart with nLite. All I can confirm is that if I had your machines in front of me, confirmed they were setup and working properly and installed Windows XP off legitimate media I could without a doubt prove you wrong.
All I can say is something is seriously screwed up with either your systems or your testing. There is nothing to rebuke because if you gave your system to someone qualified to properly test this they would either show find something wrong with your system, setup or testing.
“to the time the desktop accepts user input”
When userinit.exe closes on my PC it is at this point the PC accepts user input responsively. My PC can accept user input sooner but it is obviously still busy loading other things. Furthermore, under the “Measuring Boot Time” section of that document, it suggests to finalise timing “to the display of the desktop icons”. Now many users will agree that at this point their system will not accept user input.
The article states that their method “is helpful in assessing delays introduced by items in the Startup group, Run key, and so on.”. At the point that the Desktop shows, apps listed the registry’s Run keys and in the Startup group are still likely to be loading, which, depending on the load on the PC, presents a discrepancy between “the time the desktop accepts user input” and “the display of the desktop icons”.
My method provides a reliable and repeatable reference point to stop timing when using a stopwatch – the MS article offers no static reference point, which is why I have stated this. I agree that it may not be suitable on all PC’s, however on most systems and on a fresh install (unless the PC is under-resourced), it is a reliable reference point. People can test this for themselves and see if I’m right or wrong.
Several people have already reported their boot times reducing as a result of disabling prefetching – including on a fresh install. You have been nothing but dispositional and self-righteous in your responses, calling them liars, that it’s impossible or that their PC is seriously flawed. The fact that there are people making these claims casts doubts on your claims that prefetching benefits on ALL PC’s. I have serious doubts on your claims that Like I said. People can test for themselves. I for one don’t believe you.
Interestingly a Google search on you and your site demonstrates you have a history of misleading and abrasive activity in tech circles as well as an apparent identity crisis. For me that blows any credibility you may have once had right out of the water. Adios.
“to the time the desktop accepts user input”
When userinit.exe closes on my PC it is at this point the PC accepts user input responsively. My PC can accept user input sooner but it is obviously still busy loading other things. Furthermore, under the “Measuring Boot Time” section of that document, it suggests to finalise timing “to the display of the desktop icons”. Now many users will agree that at this point their system will not accept user input.
The article states that their method “is helpful in assessing delays introduced by items in the Startup group, Run key, and so on.”. At the point that the Desktop shows, apps listed the registry’s Run keys and in the Startup group are still likely to be loading, which, depending on the load on the PC, presents a discrepancy between “the time the desktop accepts user input” and “the display of the desktop icons”.
My method provides a reliable and repeatable reference point to stop timing when using a stopwatch – the MS article offers no static reference point, which is why I have stated this. I agree that it may not be suitable on all PC’s, however on most systems and on a fresh install (unless the PC is under-resourced), it is a reliable reference point. People can test this for themselves and see if I’m right or wrong.
Several people have already reported their boot times reducing as a result of disabling prefetching – including on a fresh install. You have been nothing but dispositional and self-righteous in your responses, calling them liars, that it’s impossible or that their PC is seriously flawed. The fact that there are people making these claims casts doubts on your claims that prefetching benefits on ALL PC’s.
Interestingly a Google search on you and your site demonstrates you have a history of misleading and abrasive activity in tech circles, as well as having an apparent identity crisis. For me that blows any credibility you may have once had right out of the water.
You all sound like a fairly well educated group (with a few exceptions), so why do none of you make mention of the fact that “Prefetch” is nothing more than virtual memory stored in a paging file or Prefetch folder (an area on the hard disk that Windows uses as if it were RAM). I have always disabled Task Scheduler on the many systems I have built and it has no effect on whether or not items appear in the Prefetch folder. On the other hand, setting paging file size to zero results in nothing in the folder. I started disabling the paging file simply because 1. I feel I have enough RAM to run the programs I use without resulting in the need of a paging file and 2. This is the primary section of the hard drive that is never defragmented when running Disk Defragmenter which was the original reason I decided to disable it in the first place. As If the swap file increases, it has to get fragmented. Reading a fragmented file is not sequential, therefore it’s slower to read. (You may have noticed that Windows deliberately tries to put the pagefile near the middle of the partition!). I noticed quicker boot times as a result and have never seen the need for having a paging file since. And yes I have used my machines for cpu intensive chores such as video editing, video capture/encoding, while running multiple applications and burning cds and watching TV on my PC at the same time. I am not a gamer however so I cannot comment of that aspect of paging file advantage/disadvantage. I will admit I do run a 3.2 HT with dual memory Corsair memory (only 1 gig at the moment) which may be more than some on this post are running. Still it is by no means a top of the line dual or quad core machine with advanced L2 mega level caches. It’s an older Northwood with the 512MB cache which I personally prefer to the hotter more power hungry 2+MB L2 cache systems that are out there today. Due to the fact that my fingers and mind are now sore I suggest that you simply disable Task Scheduler in Administrative Tools/Services and then set your paging file settings under My Computer/Properties/Advaced/Performance/Virtual Memory to “No Paging File” on your C: drive, and reboot. Then look in the Prefetch folder and you will see no files. Now go back and enable it and reboot again and use your machine awhile and files will reappear. My boot time without virtual memory is very quick and all my apps open at what appears to be the same speed that they do with it enabled, although I have never actually timed them. Also run Disk Defragmenter without a paging file and you will not see the green area that can’t be defragged that you will see with the paging file enabled. Reading a fragmented file is not sequential, it’s slower to read. One more point of interest is that if you feel you MUST HAVE A PAGING FILE/SWAP FILE, do set the minimum and maximum levels at the same values. Never leave it up to Windows to manage this for you. And if at all possible make sure your paging file is on a a different IDE/SATA cable
As i see it, if you can’t afford more RAM the fastest configuration for a swap file is:
First choice: Fixed Paging File size. If you keep Window’s default settings, the swap file will increase as needed and it will fragment very easy
Second choice: In a different faster drive (if posible) and in a different IDE cable (simultaneous reading on the same cable for IDE is not possible). That way the page file can be written/accessed faster that having to use the same bus.
Third choice: Not a very good choice IMHO, in a different (it’s own) partition
Fourth choice and obviously my personal favorite: Do not use a Paging/Swap file at all. Buy MORE RAM!
After reading my post I noticed several typos and one important neglected point.
First obvious typo:
As If the swap file increases, it has to get fragmented. (Remove “If” from the sentence.
Most obvious important neglected point:
Second choice should be First choice with info in First Choice included and my First choice should be my Second choice. (Same drive that system’s OS is located)
Now not only are my fingers and mind sore, my vision is blurring. hehe
My god 50 what you are doing is the most irresponsible thing I have ever seen anyone do online = misinform others. Anyone making any claims about disabling prefetching improving boot times is flat out testing it wrong or lying. Anyone reputable such as Ed Boot here has clearly tested it and shown that it improves performance.
The only history you found about me is my apparent futile attempt to prevent people from slowing down their systems.
Noob,
Prefetching has NOTHING TO DO WITH VIRTUAL MEMORY!!! Disabling the Task Scheduler will permanently cripple prefetching.
Your paging file information is absolutely incorrect as well. You should not disable this.
Ed, I give up the amount of ignorance online is simply too overwhelming.
Noob, disabling virtual memory is a bad idea, and setting your swap file to a fixed size is also a myth.
This comment thread has degenerated far enough. It’s now closed.
Thanks for participating, everyone.