On Fri, 11 Dec 2015 05:14:24 -0700 "Keith Medcalf" <kmedcalf at dessus.com> wrote:
> Far better is to run the queries multiple times in succession (say, > 1000) and then average the result. Good advice. Sometimes it seems like caching is "cheating": we don't know the performance of something if we're using the cache. But the cache is part of reality; it will affect performance during real-world use of the software. Pretending it doesn't exist will lead to optimizing the wrong thing. OTOH, testing can leave the cache "hotter" than it would be under normal use, depending on what "normal" is. if the OS is answering to a lot of disparate requests, SQLite will suffer more cache misses than if it's the only application running. If the data are large enough, even one table scan could remove more interesting bits from the cache. If you want to test the effect of caching, one suggestion that's been missing from this thread is umount(8). Unmounting the device is bound to release any kernel resources associated with it. Remounting it will bring only the barest information from the filesystem into memory. One difference between unmounting and using the Big Red Switch is that the drive's own cache is in play. But that cache is relatively small and afaik has a write lifetime measured in milliseconds. Unless you're reading the same 8 MB over and over, the effect of the drive cache won't skew your test results. --jkl
