Myth - "Putting the Paging File on a RAMdisk improves performance."
Reality - "Putting a Paging File in a RAM drive is a ridiculous idea in theory, and almost always a performance hit when tested under real-world workloads. You can't do this unless you have plenty of RAM and if you have plenty of RAM, you aren't hitting your paging file very often in the first place! Conversely, if you don't have plenty of RAM, dedicating some of it to a RAM drive will only increase your page fault rate. Now you might say "yeah, but those additional page faults will go faster than they otherwise would because they're satisfied in RAM." True, but it is still better to not incur them in the first place. And, you will also be increasing the page faults that have to be resolved to exe's and dll's, and the paging file in RAM won't do diddly to speed those up. But thanks to the paging file in RAM, you'll have more of them. Also: the system is ALREADY caching pages in memory. Pages lost from working sets are not written out to disk immediately (or at all if they weren't modified), and even after being written out to disk, are not assigned to another process immediately. They're kept on the modified and standby page lists, respectively. The memory access behavior of most apps being what it is, you tend to access the same sets of pages over time... so if you access a page you lost from your working set recently, odds are its contents are still in memory, on one of those lists. So you don't have to go to disk for it. Committing RAM to a RAMdisk and putting a paging file on it makes fewer pages available for those lists, making that mechanism much less effective. And even for those page faults resolved to the RAMdisk paging file, you are still having to go through the disk drivers. You don't have to for page faults resolved on the standby or modified lists. Putting a paging file on a RAMdisk is a self-evidently absurd idea in theory, and actual measurement proves it to be a terrible idea in practice. Forget about it."
This has to be one of the most over-worked tech topics on the internet.
It always happens when somebody learns what the pagefile does (or the swap partition on Linux) and what a RAMdisk is, puts two and two together and comes up with five.
Okay, YES having a page file in memory IS IN THEORY faster than having it on disk, but in real-world use, it is NOT faster than just using that same chunk of memory as... memory and leaving your pagefile on the disk.
Every argument around this topic ends up arguing for a snake eating it's tail.
Ram disk is beneficial if you need a small, super-fast hard disk for a special purpose. For example when compiling a very large project, where the compiler creates and accesses a lot of temporary files. In other cases, it hurts, because it blocks Windows from using the memory you dedicate to it. It is better to simply leave the applications running.
I actually like this idea, good point Vlastimil.
I don't doubt that there are actual usage scenarios where a managed RAM disk is a good idea, and the software in question seems like an easy way to set up and manage that.
As for your benchmark results, Kyrathaba, that's probably the THEORY portion of the argument actually working, but while memory requirements are still low, when it would be expected to.
I would put it to the test and do some things that traditionally force Windows to use up a lot of RAM and hit the pagefile on your system.
Heavy surfing with lots of tabs and all extensions enabled, then firing up Photoshop and doing some processor-intense editing, lots of blurs and transparency, edit some HTML in Word, then switch between the applications.
Then you'll REALLY see how it's doing.
I'd be curious as to the results...
Recent Posts
)
).
) we have EKOPath, LLVM and GCC on the open source front, with Intel and Microsoft on the closed path. Never bad with a bit of healthy competition