On 04/04/2013 8:02 AM, Richard Hipp wrote:
By making use of memory-mapped I/O, the current trunk of SQLite (which will
eventually become version 3.7.17 after much more refinement and testing)
can be as much as twice as fast, on some platforms and under some
workloads.
Nice!
Some quick thoughts:
1. Does this replace the page cache completely, or does it just turn
"read" and "write" into glorified memcpy calls? I would assume the
latter so that virtual tables continue to work?
2. Does sqlite3 attempt to map the entire database file, and what
happens with large files in 32-bit processes?
3. It seems like this would increase the "attack surface" for stray
pointers in the host program. Granted, writes to stray pointers are not
sqlite's fault, but they're an unfortunately common problem... and mmap
makes user bugs more likely to directly corrupt the database on disk.
Perceived reliability might drop as a result (I'm not arguing that the
risk is worth giving up 2x, just pointing it out as a potential
unintended consequence).
Thoughts?
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
