Are push times linear in the size of the repo?

[Gregory Szorc]

On Tue, Apr 14, 2015 at 12:05 PM, Michael O'Connor <mkoconnor at gmail.com>
wrote:

> I was looking at a breakdown of where the time was spent in pushing one
> empty changeset in a repo with a few hundred thousand changesets.
>
> It looks like there are a few places in the course of a push where some
> object is created that is linear in the total size of the repo (or the
> number of changesets in common between local and remote).  For example, in
> determining which changesets are outgoing (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/setdiscovery.py#l131),
> in determining which phase information to push (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/exchange.py#l144),
> and in determining information about obsolescence of future heads (see
> http://selenic.com/repo/hg/file/52ff737c63d2/mercurial/discovery.py#l276).
>
> In the third case, a patch was recently accepted to only compute this set
> when the repo actually has an obsstore, but is there a plan to eventually
> make pushing more incremental and not depend on the entire repo, or is it
> thought that this won't be a problem?  Or perhaps I've misread the
> situation?
>

In general, push times (ignoring the size of the data being exchanged) are
tied stronger to the number of DAG heads than the number of commits in a
repository. A repository with 200,000 commits and 100,000 heads will likely
take longer to push to than a repository with 10,000,000 commits and 10
heads.

There is room to optimize discovery on repos with thousands of heads. This
is a problem Mozilla has and fixing it in core and by extensions has been
discussed before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150414/485b83e6/attachment-0002.html>