My application is suffering from serious performance issues with iOS 5, can someone help me understand this speed test log with tools?

Question

I have a simple reader application that uses fmdb to communicate with a database and then populates UIWebview with text. Since the glorious appearance of ios 5 works really bad ...

When I change chapters in my book using a segmented control. In iOS 4.3, it was fast. Now, as you can see below, this is not the case:

Thus, it is obvious that things are loading slowly, but I don’t know how to read the speed test results. Which method is the main culprit? What do I need to do to optimize the application? Is there anything else I can do to understand exactly where the hangs are?

It is so difficult for me with fmdb and ios 5 that I am considering other options. Should I just give up fmdb? And go for the iOS sqlite db direct approach?

I find the tooling tool useful, but very difficult to understand and use.

UPDATE

Here is the change chapter method:

- (IBAction) changeChapter:(id)sender { if ([prevNext selectedSegmentIndex] == 0) { //previous [self setCurrentChapter:(currentChapter-1)]; } else { //next [self setCurrentChapter:(currentChapter+1)]; } [self refreshUI]; } 

UPDATE 2:

Here is the code tools tell me about is the problem. This is the following method that fmdb uses to iterate through FMResultSet:

 - (BOOL) next { int rc; BOOL retry; int numberOfRetries = 0; do { retry = NO; rc = sqlite3_step(statement.statement); //Instruments says this is 100% the problem if (SQLITE_BUSY == rc) { // this will happen if the db is locked, like if we are doing an update or insert. // in that case, retry the step... and maybe wait just 10 milliseconds. retry = YES; usleep(20); if ([parentDB busyRetryTimeout] && (numberOfRetries++ > [parentDB busyRetryTimeout])) { NSLog(@"%s:%d Database busy (%@)", __FUNCTION__, __LINE__, [parentDB databasePath]); NSLog(@"Database busy"); break; } } else if (SQLITE_DONE == rc || SQLITE_ROW == rc) { // all is well, let return. } else if (SQLITE_ERROR == rc) { NSLog(@"Error calling sqlite3_step (%d: %s) rs", rc, sqlite3_errmsg([parentDB sqliteHandle])); break; } else if (SQLITE_MISUSE == rc) { // uh oh. NSLog(@"Error calling sqlite3_step (%d: %s) rs", rc, sqlite3_errmsg([parentDB sqliteHandle])); break; } else { // wtf? NSLog(@"Unknown error calling sqlite3_step (%d: %s) rs", rc, sqlite3_errmsg([parentDB sqliteHandle])); break; } } while (retry); if (rc != SQLITE_ROW) { [self close]; } return (rc == SQLITE_ROW); } 

FMDB is all I ever knew as sqlite goes, is it even worth it? Should I just drop it and go into cocoa -touch sqlite api's?

Answer 1

Well, I really could get this information from someone on the FMDB mailing list. He suggested adding an index to my db tables, which were often called, and that fixed it!

Obviously, Apple changed the version of sqlite in iOS 5.

From the FMDB post:

Creating an index in sqlite is easy - see sqlite.org for syntax. The trick figures out which index to create. In my case, I had a query like: select a, b, c from x, where sid = somevalue; sid was not the primary key for the table, so there was no pointer to it. Adding the sid index made the query much faster, since the index allows you to quickly find tuples. Note that indexes can slow down updates, inserts, and deletes in a table, so it’s not easy to arbitrarily add indexes to your tables. Look at your queries and see which columns are used in the where section of your queries.