Using FILE_FLAG_NO_BUFFERING will return noticeable speed gain?

Question

Recently noticed detail description of FILE_FLAG_NO_BUFFERING flag in MSDN, and read several Google search results about unbuffered I/O in Windows.

http://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx

I wondering now, is it really important to consider unbuffered option in file I/O programming? Because many programs use plain old C stream I/O or C++ iostream, I didn't gave any attention to FILE_FLAG_NO_BUFFERING flag before.

Let's say we are developing photo explorer program like Picasa. If we implement unbuffered I/O, could thumbnail display speed show noticeable difference in ordinary users?

Answer 1

Oh Lord no. You make it dramatically slower by using that flag. It bypasses the file system cache, that wonderful piece of code that can guess with almost psychic accuracy that you'll want to read sector N+1 after reading N. And just pre-loads it if it is cheap to get.

It is especially bad for writing, which is why the option exists, you don't get the lazy write-back. Which means that your program can only run as fast as the disk can write. Which is very, very slow. The advantage of the flag is that you can be sure it was written. Helps implementing transactional disk updates, the kind that dbase engines care about.

But try this for yourself to see the effect.

Answer 2

No, this flag is not for typical disk users. It is for programs like databases where they need to perform their own file cache management for optimal performance. While I'm sure you could find situations where it would speed up your program, for the most part you would want to use the OS-provided buffering -- that's why it's there.

Answer 3

I recently experimented with this. Since I was already doing my own buffer management (implementing a buffer pair, which is commonly used in parsers), I figured that FILE_FLAG_NO_BUFFERING might help by avoiding extra copies. I tried different (page-aligned) buffer sizes, but it was always slower than not using the flag.

Since my scheme involved reading the entire file one time, in order, I tried FILE_FLAG_SEQUENTIAL_SCAN instead, and that actually helped a bit.

When you disable buffering, you don't get the advantage of pre-fetch and other caching tricks the OS uses. When you give the right "hint," like FILE_FLAG_SEQUENTIAL_SCAN, then you make the most out of these OS features.