Windows – Ramdisk vs Build-In IO Caching on Windows

hard driveioramdiskwindows

I'm trying to understand the built-in IO cache on Windows. If an application writes to a file, and then reads/writes it multiple subsequent times, it seems that the IO cache should allow this to happen as fast as system memory will allow? Then Windows will gradually write changes back to the physical disk in a non-blocking way?

However, I've seen other ramdisk-related questions on this site where users see significant gains by mounting a portion of system memory as a disk drive. If the IO cache works as I described above, why is this even necessary? Does Windows have settings to tweak this?

These lead up to my real question: Is there a point to using a ramdisk and manually syncing changes back to a physical disk, even minutes or hours later?

Edit: Fixed DMA vs IO Cache misconception corrected in Evan Anderson's reply.

Best Answer

I think you're confusing the functionality of direct memory access (DMA, a hardware feature) with the features provided by the Cache Manager in Windows.

DMA is a method to allow IO devices to directly access system memory without CPU intervention. Applications don't use DMA-- device drivers do. Applications are far removed from the DMA process.

Applications' read / write requests pass through a variety of layers on the way to the IO device. The Cache Manager is going to handle the bulk of caching of requests via system memory. Device drivers of the IO devices themselves may also implement caching.

If your application doesn't interact well with the Cache Manager but does with a RAM disk (which you'd determine by benchmarking) then, by all means, use a RAM disk. To me there's little point about academically dancing around the subjective "good" of various technologies. In terms of a production deployment, the key to whether there's a "point" to using a given technology should be based on benchmark with as close to real-world conditions as you can simulate. When you make changes to the OS, driver stack, application code, etc, you should redo your benchmarks since your old assumptions may no longer hold true.