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 5f9bf51438a16b73d6fcf30f3ca43fbb894ea5df ... so done! --Joey