This disk cache effect is pretty well known on this list. Mozilla/Firefox also uses a similar technique for its sqlite database:
http://developer.mozilla.org/en/docs/Storage:Performance#Priming_the_cache They go to the extra step of populating the sqlite page cache with some custom code: http://mxr.mozilla.org/mozilla/source/db/sqlite3/preload-cache.patch This patch probably won't work with the sqlite 3.5.x series without modification. But I don't think it's worth the hassle when a plain 'file read and discard' without modifying sqlite code delivers comparable results for most (all?) desktop OSes with file caches, as you've discovered. --- Julien Renggli <[EMAIL PROTECTED]> wrote: > I then had the following idea: SQLite is probably reading the file > randomly, depending on where the data lies. If I can force the DB to be > cached, everything should be fine. So before connecting the database, I > first read it sequentially (using a C++ ifstream) until the end of file. > > It perfectly solves the database problem, even though I still notice a > difference (3s to read the file on 1st run, 0.2s later). But 3s is OK > where 30s was worrying me. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
