Code review comment for lp://qastaging/~uriboni/webbrowser-app/newtabview-listviews

I did some profiling on my laptop, comparing the performance of this branch and trunk with a large bookmarks database.

The first set of tests was with a database of 10000 bookmarks (100 folders with 100 URLs in each). In that case, this branch performs slightly better than trunk. The binding on internal.seeMoreBookmarksView for the 'active' property of bookmarksFolderListViewLoader takes 260ms to execute with this branch, vs 330ms with trunk. From a user perspective, there’s no perceived difference, the view takes about half a second to load and be responsive with both branches.

With a database of 100000 bookmarks (100 folders with 1000 URLs in each), trunk performs significantly better than this branch. The binding on internal.seeMoreBookmarksView for the 'active' property of bookmarksFolderListViewLoader takes 2.2s to execute with this branch, vs 1.9s with trunk. But more importantly, it takes ~7s for the view to load and be responsive with this branch, compared to ~3s with trunk.

If we want to optimize for large bookmark databases, this branch doesn’t appear to be improving things, quite the contrary. All of this is anecdotal when we look at the time it takes for the application itself to launch and become responsive though. With 100000 bookmarks, the app takes ~20s to launch. So if we really want to optimize for this use case, we need to remove the loading of the model from the critical startup path, before doing any optimization work on the bookmarks view.

The databases I used for profiling are available there: http://people.canonical.com/~osomon/lotsofbookmarks/.