I think however our lower boundary is 0.05 seconds since we do commits after insert events is called, which is a disk write. Now we could avoid that by first returning the values to the user then commiting... It will save noticeable time.
Also:
I tried setting journal_mode to WAL
Speed improvement from 1.5 to 0.5 - 1.0
Better...
The WAL journaling mode uses a write-ahead log instead of a rollback journal to implement transactions. The WAL journaling mode is persistent; after being set it stays in effect across multiple database connections and after closing and reopening the database. A database in WAL journaling mode can only be accessed by SQLite version 3.7.0 or later.
I think however our lower boundary is 0.05 seconds since we do commits after insert events is called, which is a disk write. Now we could avoid that by first returning the values to the user then commiting... It will save noticeable time.
Also:
I tried setting journal_mode to WAL
Speed improvement from 1.5 to 0.5 - 1.0
Better...
The WAL journaling mode uses a write-ahead log instead of a rollback journal to implement transactions. The WAL journaling mode is persistent; after being set it stays in effect across multiple database connections and after closing and reopening the database. A database in WAL journaling mode can only be accessed by SQLite version 3.7.0 or later.
More info can be found here: http:// www.sqlite. org/wal. html