Mini Nugget: Windows 7 "Standby" memory a.k.a. File Cache

[Intaris]

I ran into an interesting behaviour recently when *attempting* to benchmark SQLite.  I was seeing some weirdly unreproducible behaviour and when I started to think about it a bit more, some very unexpectedly FAST read speeds from a HDD.

It turns out that Windows 7 is far more intelligent than I ever imagined.  I at least was completely unaware of this behaviour. 

Every time a file is read from or written to, Windows 7 will cache this information in memory and redirect file access to the momory location.  Should this memory space be requested by any process (It's not marked as occupied) then the OS releases the data from memory and allocates to the process requesting it instead.

I was performing a query in a 12GB SQLite file when I had to stop the benchmark half way through.  Each iteration up to that point (Reading in later and later portions of the file) took approximately 300ms.  When I re-ran the benchmark immediately after, the iterations which had already been performed previously zoomed past at 0-1ms each whereas the iterations which had been aborted still took around 300 ms each.

There is a free tool called RamMAP from sysinternals which allows a user to observe, document and also clear such memory allocations.  It is possible to completely clear the "Standby" memors (used for file cache) in order to get back to "baseline" benchmarking.  So anyone interested in performing disk access testing, make sure to check that your disk is actually involved before staking any important decisions ont he numbers you observe.

Interesting side-effect: This RAM cache is OS-implemented so even 32-bit LabVIEW benefits from loads of RAM on a Win7 64-bit platform when accessing huge files.  Yesterday during testing I had an entire 8.5GB SQlite file in RAM......  But note that the caching is very granular, if you access the file a few kB off the last read, it probably isn't cached and will require actual disk access.

[Darren]

Good nugget. When we benchmark LabVIEW performance, particularly with loading large VI hierarchies, we always have two numbers...the "cold" load time and the "warm" load time. Cold is when the files have never been accessed since the last reboot, and warm is when they're in the OS file cache. Warm load time numbers, as you would expect based on your post, are much much faster.

[*3d0g]

Great tip!  Thank you.