git-annex sync, when run in a view branch, regenerates the view branch from
scratch. That is as expensive as entering the view branch in the first
place, which can take quite a long time when there are a lot of files.

And users with a lot of files are just the kind of user a view branch
appeals to..

There is probably a lot of scope for optimisation in updating the view
branch, that might be able to get it reasonably quick. 
I have not fully thought through it, but basically diffing from the old
parent branch to the new parent to find files that have changed, and
adding/removing those from the view. And also diffing from the old
git-annex branch tree to the new one to get changes to metadata logs,
parsing those and using changes to metadata to also move/delete/add
files to the view branch.

It may also be that just improving the precaching of metadata logs
would improve the speed a lot. The streaming precaching of location logs
sped up some commands around 2x before IIRC.

> catObjectStream of metadata logs sped view constriction up by ~50%.
> More streaming should speed it up more; it still uses
> lookupKey/catKey once per file. --[[Joey]]

> Seems like this was implemented in
> [[!commit 5f9bf51438a16b73d6fcf30f3ca43fbb894ea5df]]
> ... so [[done]]! --[[Joey]]
