I'll be presenting some more details at the UKUUG LISA conference in Edinburgh
in 2 days. Just a quick note here...
SQLite 126.96.36.199 (unmodified) took ~22.43 seconds to insert 1000
randomly-ordered records on my laptop (with Samsung SSD). The SQLite modified
to use MDB took only 1.06 seconds.
This 20:1 improvement in write performance is most significant in terms of
absolute efficiency. Given how pervasively SQLite is used in Android and apps
like Firefox, on smartphones, tablets, and other battery-powered devices,
there's a potential to significantly increase the runtimes of these devices by
switching to SQLite+MDB.
Read efficiency is somewhat of a lost cause, >95% of the CPU time in reads is
spent in the SQL parser. Even though MDB is much more efficient at reads than
stock SQLite, the difference is lost in the noise under the parser overhead.
I believe, for the vast majority of situations where SQLite is embedded in
applications, significant efficiency gains would be obtained by using a pure
binary data interface. While a simple key-value interface may be too primitive
for app convenience, an inline implementation of the X.500 data model (with
indexing) may be more useful. I.e., slapd back-mdb turned into an application
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/