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

> 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.

This bottleneck is essentially the time that it takes to expand the bookmarks view.
I did some tests with your 100K model, which has 100 folders, and another model which has 100K bookmarks but no folders.
Yours took 220ms on my machine, the other 8ms.

What is causing the difference is having to allocate each single folder/section placeholder model.

So basically the problem is now shifted from making the performance proportional to the number of bookmarks, to having the performance proportional to the number of folders. It is less of a problem but of course still a problem since we can't control the number of folders that the user can create.