I\'m using a compiled SQLiteStatement
with transactions in optimizing SQLite transactions but I\'m reading the documentation for the execute function:
execute
is probably not faster than executeInsert
, could even be slower (on ICS execute calls executeUpdateDelete
and discards the return value). You need to test that but I doubt you will find a real difference here.
AFAIK, It is safe to use just execute
if you don't need return values but I would not count on that holding true in future Android versions. The documentation says no, so maybe someone is going to change the behavior to reflect that. Older implementations seem to use execute
too (e.g. 2.1 delete() sourcecode). Jelly Bean for example changed a lot behind the scenes of SQLite, but it should still work when using execute
Besides, if you don't use the same SQLiteStatement
over and over again while just rebinding the args it's probably not worth using it. Building a new one each time you call the regular insert
, update
, ... methods is fast compared to the actual database access and the required disk I/O. Transactions on the other hand help a lot, since synchronizing database state on the disk for each statement is really slow.
Use SQLiteDatabase instead of SQLiteStatement for intereacting with your database. SQLiteStatements are not Thread safe so I would not use them for SELECT / INSERT / DELETE / UPDATE. Also you should try not to use raw database queries for anything other than Selects
. There are built in helper functions that will increase your database performance. On your instance of SQLiteDatabase
you have .insert, .update, .delete and I use .rawQuery for Selects.