Comment 25 for bug 582157

That's certainly much better. More could be done but perhaps this
specific bug should be closed, and we can identify some others to do
next.

A few questions:

 * how close is 170kB/s to saturating your local link?
 * are there any obviously inefficient hpss calls (there probably are
too many graph calls, and that would be clearly a different bug)
 * is 11.5MB a reasonable size for the amount of actual change in that
repo from r10721 to r10876?

> Looking closer at the -Dhpss logging: the get_stream request was sent at
> 28.7s and the response was finished some time before 92.9s, and the
> total bytes sent in that one response was 10992877 (combined *.pack and
> *.?ix files on disk after the transfer are 9.7M, FWIW), so that's
> ~170kB/s for the stream itself.  The original report was 21K/s (and
> nearly 13 minutes, rather than nearly 2).

Taking 28.7s before starting to send bulk data is a bit high.

>
> I think that's probably good enough to consider this specific report
> closed.  What do other people think?

I think so. I don't like having very broad bugs open that are going
to stay open until we reach some kind of asymptotically good
performance. On the other hand it is nice to have a few clear leading
bugs to point users and developers to.

--
Martin