I have 4 GB of RAM and would like to make use of ReadyBoost to speed up hard drive access, by taking advantage of its hard drive cache method.

However, as I understand the technology, ReadyBoost focus is reducing RAM usage, instead of increasing hard drive access times. That is, before anything gets sent to RAM, if it can be stored in the ReadyBoost enabled pen drive, it will.

For a 4GB system that doesn't do much memory paging between RAM and the hard drive, isn't this going to actually make my system run slower since reading access times on a USB flash drive, while faster than on a hard drive, is still much slower than on RAM?

Or, in other words, does ReadyBoost slow down systems with more RAM than what they usually require?

  • ReadyBoost won't slow down your system. The precache is loaded earlier whether you use the apps or not. But boot time gets longer with every increase of RAM since there is more that can be loaded from disk. – Abraxas Jul 23 '11 at 17:12
  • > "But boot time gets longer with every increase of RAM since there is more that can be loaded from disk." No. Windows is demand-paged. If you run the same program the same way on two different machines, one small and one large, both instances will access the same parts of their address space and so will fault in the same stuff. But on the smaller system, some of the stuff read in earlier may have to be evicted from RAM (maybe written to disk if it's been changed; definitely read in again later if it's needed again) in order to make room for later stuff. So the smaller system is slower. – Jamie Hanrahan Sep 26 '15 at 2:48
  • And if you're thinking that SuperFetch will opportunistically prefetch more stuff on the larger system? Well, that is true, but it won't result in longer boot times. You don't have to wait for SF to load up its cache before "boot time" is over and you can use the machine. And SF uses low-priority IO requests, so ordinary IOs from apps don't don't have to wait in line behind them. – Jamie Hanrahan Sep 26 '15 at 2:52

I don't know that I agree with the statement: "ReadyBoost focus is reducing RAM usage, instead of increasing hard drive access times."

It is primarily used for caching files, so they do not have to be read from the hard disk again, which is slower. Unless you have an SSD drive, I believe you would probably notice the difference. I saw a big difference, especially with things associated with the Interface.



On Windows Vista, less-than-mature algorithms did lead to reduced performance with ReadyBoost enabled on a system with large amounts of memory. These algorithms were improved with Windows 7 such that even a system with large amounts of RAM would benefit from ReadyBoost, and repeatable performance gains have been reported. See this blog post for more details.

With commonly accessed data, ReadyBoost uses the flash memory cache for small random reads in tandem with the hard drive for large sequential reads, taking advantage of the fast random I/O characteristics of flash memory. However, flash memory is usually slower for sequential I/O than hard drives. It appears that algorithms related to this process were poorly tuned with Windows Vista, but this been resolved with Windows 7.


ReadyBoost is NOT a cache. It is a mirror for your swap file. The most used virtual memory pages go there, and to HDD both. That is the reason, why there is no reason using it in systems where both SSD and HDD present - IT IS NOT A CACHE.

The problem is that WIndows decides where to read from basing on disk load. But during heavy and average CPU load it still prefers USB. Attempting avoid HDD interface bottleneck, it hits the system I/O bottleneck. It still has to do a lot of work with NAND flash, and then buffer and decrypt the data, before fetching it to physical RAM. So, it often happens, that ReadyBoost not boosting, but freezing the Windows down.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.