Custom Prefetch

I am not aware of a Win32 (NT) API similar to madvise().

However, I would suggest an approach.

First, pass the Win32 flag FILE_FLAG_SEQUENTIAL_SCAN to CreateFile(). This will allow the Windows operating system to perform better buffering of the file once you have opened it.

With FILE_FLAG_SEQUENTIAL_SCAN, your file parser may operate more quickly once the file is in memory. Unlike madvise() on Linux, the file will not begin loading into memory any earlier due to the use of the Win32 flag.

Next, we need to trigger the file to begin loading. Asynchronously read the first page of the file by calling ReadFileEx() with an OVERLAPPED structure and a FileIOCompletionRoutine function.

Your FileIOCompletionRoutine can simply return, or you can set the event in the overlapped structure -- read the MSDN details of ReadFileEx for details.

Since it would not be a critical failure if the pre-fetch hasn't completed when you actually read from the file, the easiest implementation would be to "fire and forget" -- execute the overlapped file read and then never check the result of it. Be sure that you read the data into valid buffers, though!

If you perform this operation for a file while reading the previous file, the result should be that the next file will commence paging in.

Be aware that this may slow your performance. As the next file begins to page in, the disk I/O to access that file will compete with disk I/O for the file you are currently parsing. If the two files are physically distant from each other on the same disk, the result of pre-fetching might be additional delay as the drive head seeks. Although modern drives have huge buffers which mitigate this, queuing the first page of a new file is likely to cause a head seek.

bdonlan's suggestion of a 'pre-fetch' thread which loads the files asynchronously from the processing would be a workable solution for Win32, also.

yes.. and that more portable option would, in a way, force an OS (to a reasonable consumption) for its existing buffering or prefetch qualification mechanism. I am already utilising it in a way, but not via threads as the procedure spans process lifetimes.. Thus the interest in hinting to the OS, and especially for large turnover of files. Thanks and upvoting both answers..

rama-jka toti 2009-10-13 22:27:30

You can still use the readahead-thread option - put it in a seperate process that spans the lifetime of the other processes, and pass data across shared memory. It's more complex, certainly, but it's doable.

bdonlan 2009-10-15 08:06:37

cheers for both of your comments..Am aware of the file_flag_sequential and suggested techniques but I was wondering whether there is any explicit control on what remains: XP+ OS-es for prefetch it so advertises say in SuperFetch and other forms :) Kind of a shame if there isn't a way to do it, as it obviously is in function on NT, even more obviously than Linux I'd say. Then again, I might be missing something as I searched for explicit control but to no avail.. will let the question run for a day before accepting an answer or more suggestions. Thanks..

rama-jka toti 2009-10-13 22:20:52

I believe that SuperFetch is only a little more than a 'pre-fetch' thread, although in this case: it is an entire process rather than a thread, somehow it obtains information from the OS allowing it to make decisions about which EXE and DLL files to bring into memory.

Heath Hunnicutt 2009-10-13 22:58:10

After sleeping on it, I have expanded upon my answer with regard to Win NT.

Heath Hunnicutt 2009-10-15 03:52:57

As bdonlan had two upvotes :), I'll accept yours although you both technically answered it. I would only add that I would shy away from OS specific mechanisms via asio and gain the best of both worlds.. Still a pitty that there is no explicit mechanisms for where you can and want to control a large chunk of OS prefetching..

rama-jka toti 2009-10-15 07:02:50

ansaurus

tags:

views:

answers:

related questions