codinguser/gnucash-android — pull request #188 by fefe982 (2014-08-30 01:20:35+00:00)
Title: Improve the processing spee of the App

It used to take more than 10min (689.8s) to import my big book. Now it takes only 44.2s.

Introduced bulk import mode for XML import. (The original import mode is also left there. The two import mode can be switched easily on code level.)

Main modifications on bulk mode:
1. Account, Transaction, Split are not inserted into the db when they are encountered. The information are gather and saved, and they are all inserted into the db at the end of the parsing the XML file.
2. `beginTransation()`, `setsetTransactionSuccessful()`, `endTransaction()` methods are used to control db transactions, thus _all or none_ of the accounts (or transaction, splits) would be inserted/updated into the db.
3. `SQLiteStatement` is used instead `insert` or `update` call. (Several articles [like this](http://www.techrepublic.com/blog/software-engineer/turbocharge-your-sqlite-inserts-on-android/) claims this should much faster)
4. `REPLACE INTO` SQL statement is used instead of the original _'query and insert/update'_ approach.
5. Transaction's exported state will not be modified when inserting Splits.
6. Full name of Account is not generated after the insertion. They must be generated before the insertion.

These modifications used a faster db insertion approach, and eliminated a lot of db access.

Import time comparison after applying 498bf48 (times are in seconds):

Test file | before | after | db access time
----- | ---- | ---- | ----
File1 | 689.828 | 43.084 | 9.103
File2 | 16.119 | 1.767 | 0.509

File 1 contains 257 accounts, 8448 transactions and 17333 splits.
File 2 contains 39 accounts, 205 transactions and 412 splits
The 'db access time' is the time used by bulk insertion after the commit. It is hard to calculate the db access time before the commit as they are scattered everywhere during import process.

Note in debug mode (when you hit 'debug' in the IDE instead of 'run'), the App can be much slower, and will take 30min to import File1 before the commit and 8min after.

Possible defects:
1. Exceptions during db insertion are caught, so the main import procedure will not know about them and report success. May consider re-throwing.
2. Insertion of Accounts, Transaction and Splits are independent. So there is a possibility that all accounts are imported, but no transactions or splits, or all transactions are imported but no splits. I think the former may be tolerable, but the latter may cause problems.

More commits may follow up to deal with the defects.

More commits may also follow up in the performance improvements in other parts of the App ( Such as balance calculation, exporting, etc). Do you think it is appropriate to put them all here? Or should I use new pull request?