Question

I have a SQLite database with with just over 6,000 rows of addresses in a table. This is a read-only database – no updates or changes after the app is built and deployed. I have an index on the state field. My app uses a simple select statement to get all rows that match the given state. I have used the explain and explain query plan statements to see that my query is using the index.

Most of the time the query comes back in under a second – not great, but good enough for my application.

Every so often the query takes longer – even up to 14 seconds, often 3-4 seconds. Exact same query on the exact same read-only database (and table) on the same phone, invoked by the exact same binary.

I can see that no garbage collection is occurring, and no exceptions are being generated from monitoring logcat

There is just a variation that sometimes occurs. A variation that creates an inconsistent user experience.

It appears that the SQLite database system is being shared by other apps – such as the email client. Could it be that my query is being queued behind another app’s queries and thus the variation is due to when the shared SQLite database system actually gets to run my query? If this is the case, is it possible to “create my own SQLite instance” so that I can get consistent performance?

If it is not a shared SQLite database system (and thus I do have my own instance) what else could be causing such a large variation in query performance given that everything else is equal?

Note that I can’t easily bring the data into memory to run the query there as the rows are pretty long (have more information than just the address) and I have a number of other parts of my code that make use of more complex select queries. I’ve narrowed the performance variation down to just the simplest “select where state = ” query for this question (plea for help).

Answer 1

It appears that the SQLite database system is being shared by other apps – such as the email client.

Not exactly. Storage is shared by other apps. And on Android 1.x and most 2.x devices, internal storage is formatted YAFFS2, which only allows one process to access the storage at a time. This should be less of a problem on Android 3.0+ devices (and some 2.3 devices) that are running ext4 instead of YAFFS2.

Could it be that my query is being queued behind another app’s queries and thus the variation is due to when the shared SQLite database system actually gets to run my query?

Not exactly. Your disk I/O could be queued behind another app’s disk I/O, though.