Develop Reference

Sqlite insert performance for smartphone

I'm trying to optimize the insertion speed for sqlite in android. I've tried numerous methods. Like setting the pragma settings, journal mode and etc.
Besides that, i've also tried individual inserts, prepared statement and bulk insert. Keep in mind that all of those has already been wrapped in a transaction.
The insertion speed in my smartphone(Samsung Galaxy SIII) is only up to about 250 rows per second for a 20 column table. According to Sqlite faq, sqlite can easily insert 50,000 inserts per second. Therefore, i'm really optimistic about the insert to have at least up to the thousands rather than hundreds. However, none of the above mentioned works. Or 250 rows of inserts is already optimized?
Please help me. Thanks.
Regards,
Dexter

One method I use on big company sized databases to increase bulk insert speed is to turn off indexing while doing bulk inserts. The drawback is you need to have exclusive access to the database and you have to turn indexing back on when your done.
In a mobile app you could easily get exclusive access to the database by putting up an "Updating the app" screen.
SQLITE you can drop any non unique indexes before performing the bulk insert. If your 20 column table has 20 non unique indexes (one for each column). Drop the 20 indexes. Perform the bulk inserts. Create the 20 indexes you previously dropped.
Also make sure your code is compact and doesn't do anything inside the insert loop that could be done before the loop. For example look up column indexes before your insert loop.
If this doesn't apply to your app just catalog it away as something you may need to do in the future on your back end database.

You can use Object/Relational Mapping (ORM) tool for better performance.
ORMLite, GreenDao etc.
Greendao is better one, have a look
http://greendao-orm.com/
Features :-
Maximum performance (probably the fastest ORM for Android)
Easy to use APIs
Highly optimized for Android
Minimal memory consumption
Small library size, focus on the essentials
Benefits of ORM tools :-
ORM can give you Relational Persistence, which results fastest performance.
Less development work

ORMLite or SQLite in android

Why we use ORMLite, if we already have Sqlite in Android ?
Is there any specific reason behind the ORMLite to use over SQLite in Android?

ORMLite is an open source software framework that provides lightweight object relational mapping (ORM) between Java classes and SQL databases.
ORMLite has two .jar files : ormlite-core.jar (275KB) and ormlite-android (50KB) libraries
Pros :-
1.)use for complicated database operations
2.)no need to remember to SQL queries
3.)prefer for big size application
Cons :-
1.) unnecessarily increase size of application
2.) little bit slow with compare to greenDao(another ORM)

To choose your ORM in android, also look at these links:
Bench marking ORMs in Comparison of SQLite
Comparison of GreenDao and ORMLITE

Android SqlCipher Performance issue

We integrate the SqlCiper sqlite db into our Android project. What we found out that there is some big difference of db query performance in unecrypted SqlCiper sqlite db and encrypted SqlCiper sqlite db.
We just did some basic timing logging at our code on same Android device:
unencrypted SqlCiper db: 100 db query, total time: 1-2 seconds
encrypted SqlCiper db: 100 db query, total time: 17 seconds.
As you could see that there is big increase in the running time when encryption is turned on in SqlCiper database.
Based on this post: SqlCiper Performance and SqlCiperSpeed, we won't see such big increase on iOS, however I didn't see any performance number on Android.
Do you guys see the same issues as we saw? Any suggestions to improve it?

First, ensure that you have a problem worth worrying about. A query that takes 170ms, instead of 10ms, is unlikely to be a material difference to the user, in isolation. In either case, you need to be using a background thread, as even 10ms is enough to cause you to drop a frame or two, depending on what else is going on. Hence, if you are doing this query in response to some discrete user request (e.g., tapping on an action item), the user is unlikely to notice the difference. Only if you are doing a lot of these queries in a short time frame are you likely to have speed issues that might cause problems for the user.
Second, ensure that you have tuned your database access in general, using things like the EXPLAIN keyword. SQLCipher for Android makes poor database I/O worse, such as queries that result in table scans (e.g., due to not having the right indices).
Third, use Traceview to determine precisely where your time is being spent.

You can optimized by the way:
1.In SQLCipher lib, used AES algorithm to encrypt data. --> You can change AES --> RC4. Performance increased 10-15%. (You can compared AES & RC4 before use it)
2.Important you shoud optimize data SQLite (create index, sql query,...);
http://www.sqlite.org/optoverview.html

Arguments for and against the Android SQLite usage

I am unsure if I should use or not Android SQLite database with my Android program.
The program has several tables, and I have operations for quering, updating and displaying these tables. However the total amount of data is not very large (maybe tens of rows at most).
I was told by some people that I should not use databases any more as storing everything into flat files is easier to implement, the finished implementation is easier to maintain and the database engine can be replaced by collection framework that stores pre-loaded flat files. These people have some weight in decision making so I need argumentation if I still want to use the database.
Would it be possible to get argumentation when Android SQLite database should and when it should not be used?

The concept of a ContentProvider abstracts away from the actual technique used to persist your data. It allows you to nicely separate the implementation of your data source and the visualization of this data. In this respect, I don't think that easiness of implementation is a good argument for or against SQLite. If you use Cursors, you probably will use a ContentProvider anyway.
If you perform a lot of (complext) queries, the query performance might be an argument in favor of SQLite since this is what is is built for. Moreover, it seems much easier to debug an SQL database than a flat file.

SQLite or Serialization

I'm writing an application which needs to store data. A single pack of data is about 4 classes with many dependencies between them. For example, class A has a list of objects B and B has a list of objects C and few more dependencies...
And I wonder what would be better. Keep them in SQLite db or serialize each pack separately and store them in serialized files?

For me the only right solution would be to save the data inside a database especially if there are any dependencies. For beginners it might be hard at the beginning to get into database creation. but after you have created a database in the right form you just have to insert the data and you won't have any problems in the future if you want to change something or expand your app. With simple serialisation the logic has to be solved inside the app and might cause more problems especially if you have any dependencies.
If you need a good tutorial for saving data you should look at this tutorial
http://thenewboston.org/watch.php?cat=6&number=111
For other different solutions for saving data there are also some tutorials on the website, Nr. 108 - 110 of Android programming

IT depends on the usage of the data. You may do well choosing JSON/GSON serialization and avoid the overhead of doing ORM over SQLite. (Overhead meaning additional coding to marshall to/from the db) However, if your data is subject to growth or something that would be better managed by a db (a lot of non-sequential or random access across a larger data set) then go for SQLite and ORM. In the end it comes down to what type of data you are trying to manage. Again if your data set is something that could grow and involves a lot of random access it may be worth using SQLite.