Comment 6 for bug 526825

I think I've seen less severe forms of this with 2a branches too. After the server receives a Repository.get_stream_1.19 request it has to do some work before it can start streaming records back: figuring out the set of revisions described by the request's params at least. For an 'unordered' or 'groupcompress' stream ordering, I'd hope this preliminary work is quite fast, and then goes straight into streaming records from the repo.

But as Robert says, for cross-format streams I think the ordering sends texts first, so that means a lot of reading of revisions->inventories->texts to find the texts-changed-in-revs data before it even starts, so I suspect that's what's happening here. It may be possible to improve.