How do I efficiently update a UITableView with Animation?

This question actually has three answers. That is, there are three parts to this question:

1. How to keep the UI responsive
2. How to keep the updating fast
3. How to make table update animation smooth

UI Responsiveness

To solve the first problem, I now make sure that no more than one table-updating message can be delivered on each iteration of the main event loop. That prevents the main thread from locking up if the background thread is feeding it stuff to do faster than it can cope with it.

This is done thanks to example code sent to me by Byline author Milo Bird, which I then integrated into Dave Dribin's DDInvocationGrabber. This interface makes it super easy to queue a method to be invoked on the next available iteration of the main event loop:

[[(id)delegate queueOnMainThread]
    parserParsedEntries:parsedEntries
               inPortal:parsedPortal];

I quite like how easy it is to use this method. The parser now uses it to call all of the delegate methods, most of which update the UI. I've released this code on GitHub.

Performance

As for performance, I was originally updating one UITableView row at a time. This was effective, but somewhat inefficient. I went back and studied the XMLPerformance example, where I noticed that the parser was waiting until it had collected 10 items before dispatching to the main thread to update the table. This was key to keeping the performance up without making the UI lock up by updating all 500 rows at once. I played around with updating 1, 10, and all 500 rows in a single call, and updating 10 seemed to offer the best tradeoff between performance and UI lockup. five would probably work pretty well, too.

Animation

And finally, there's the animation. Watching the “Mastering Table Views” WWDC 2010 session, I realized that my use of the deleteRowsAtIndexPaths:withRowAnimation: and updateRowsAtIndexPaths:withRowAnimation: methods was wrong. I had been keeping track of where things should be added and removed in the table and adjusting the indexes as appropriate, but it turns out that's not necessary. Inside a table update block, one only needs to reference the index of a row from before the update, regardless of how many may be inserted or deleted to change its position. The update block, apparently, does all that bookkeeping for you. (Go to about the 8:45 mark in the video for the key example).

Thus, the delegate method that updates the table for the number of entries passed to it by the parser (currently 10-at-a-time) now explicitly tracks the positions of rows to be updated or deleted from before the update block, like so:

NSMutableDictionary *oldIndexFor = [NSMutableDictionary dictionaryWithCapacity:posts.count];
int i = 0;
for (PostModel *e in  posts) {
    [oldIndexFor setObject:[NSNumber numberWithInt:i++] forKey:e.ident];
}

NSMutableArray *insertPaths = [NSMutableArray array];
NSMutableArray *deletePaths = [NSMutableArray array];
NSMutableArray *reloadPaths = [NSMutableArray array];
BOOL modified = NO;

for (PostModel *entry in entries) {
    NSNumber *num = [oldIndexFor objectForKey:entry.ident];
    NSIndexPath *path = [NSIndexPath indexPathForRow:currentPostIndex inSection:0];
    if (num == nil) {
        modified = YES;
        [insertPaths addObject:path];
        [posts insertObject:entry atIndex:currentPostIndex];
    } else {
        // Find its current position in the array.
        NSUInteger foundAt = [posts indexOfObject:entry];
        if (foundAt == currentPostIndex) {
            // Reload it if it has changed.
            if (entry.savedState != PostModelSavedStateUnmodified) {
                modified = YES;
                [posts replaceObjectAtIndex:foundAt withObject:entry];
                [reloadPaths addObject:[NSIndexPath indexPathForRow:num.intValue inSection:0]];
            }
        } else {
            // Move it.
            modified = YES;
            [posts removeObjectAtIndex:foundAt];
            [posts insertObject:entry atIndex:currentPostIndex];
            [insertPaths addObject:path];
            [deletePaths addObject:[NSIndexPath indexPathForRow:num.intValue inSection:0]];
        }
    }
    currentPostIndex++;
}
if (modified) {
    [tableView beginUpdates];
    [tableView insertRowsAtIndexPaths:insertPaths withRowAnimation:UITableViewRowAnimationTop];
    [tableView deleteRowsAtIndexPaths:deletePaths withRowAnimation:UITableViewRowAnimationBottom];
    [tableView reloadRowsAtIndexPaths:reloadPaths withRowAnimation:UITableViewRowAnimationFade];
    [tableView endUpdates];
}

Comments welcome. It's entirely possible that there are more efficient ways to do this (the use of -[NSArray indexOfObject:] is particularly suspicious to me), and that I may have missed some other subtlety.

But even so, this is a huge improvement for my app. The UI now stays (mostly) responsive during a sync, the sync is fast, and the table update animation looks just about right.