I don’t work much with the internals of Windows, but I’m developing a desktop Java based rich client on XP/Vista that can have up to about a 20 meg local cache consisting of about 2000 files. Upon running the client for the 1st time the cache initializes rather slowly as I assume each file is getting loaded into the system file cache. If the client is restarted the client cache loads reasonably fast as I assume most if all the files are already in the system file cache. If the program or the computer is left on for roughly a day and then the client is restarted the cache initialization is slow again (files have been removed from system file cache); a subsequent restart and it’s fast.
I’ve read up a bit about the system file cache and what not and am curious if there is a way at the kernel level to “prefetch” a whole directory into the system file cache instead of individual I/O operations on each file triggering it’s load into the system file cache. I read about the virtual block basis for the cache manager and realize it is not logical block oriented, but is there a way to promote a whole directory of files into the system file cache easily, so that the client program can initialize it’s cache efficiently on the 1st and every execution?
I couldn’t locate any function in kernel32.dll that touched upon this kind of thing. If something like this is possible I’d like to hear about how to do it or if not I am certainly interested on possible techniques to speed up the initial client cache loading regarding the system file cache.
You can’t affect cache manager behavior from user mode, however there is another way to do what you want. You can map each of 2000 files into the process memory (CreateFileMapping and MapViewOfFile), 20 megs should easily fit your process address space. Then read one byte from each page (each 4K) of each mapping, this will force system to bring all files into memory.
However, I would not force system to fetch all data from disk at once, but better postpone each fetch operation when it is really necessary.