On 8/10/10, Paweł Hajdan, Jr. <phajdan...@chromium.org> wrote: > So this is another chromium patch I'd like to submit: > http://src.chromium.org/viewvc/chrome/trunk/src/third_party/sqlite/preload-cache.patch?revision=26596&view=markup > > I'm not the author of that one, but the main idea seems to be that with > preloading we get better performance with many scenarios chromium uses > sqlite (like for omnibox local suggestions). What do you think about the > patch and the idea? Is there better way to do the same thing? Would you like > to see some benchmarks?
The benefit of preloading is to replace random I/O with sequential I/O. I have definitely seen this be effective in some cases. For those who want something like this, doing a cat or dd command, or using OS reads in a loop, will probably give the same benefit: the database won't be loaded into SQLite's cache, but will be loaded into the OS buffer cache. An advantage of preloading outside SQLite is that the dd/cat/read could happen in a separate thread, so it wouldn't impact app startup time. And it could be that one use of a database might benefit from preloading, whereas another use might not, so it seems that preloading inside SQLite would have to be something requested with a pragma rather than always happening by default. What I would like to see more than SQLite preloading is better page allocation strategies and incremental defragmentation, to cut down on the amount of random I/O and keep related pages in sequential order. Jim -- HashBackup: easy onsite and offsite Unix backup http://sites.google.com/site/hashbackup _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
