Re: Updates on Mercurial

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Wed, Dec 23, 2020 at 07:26:53PM -0800, bch wrote:
> On Wed, Dec 23, 2020 at 16:16 Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> 
> > Hi all,
> > after a busy time this summer, I finally got a chance to come back to
> > working on the TODO list for Mercurial during fall. Quite a few things
> > have changed or have pending patches under review:
> >
> > (1) Memory use during large operations and especially the initial clone
> > has much reduced. On AMD64, the unbundle of src's clonebundle as
> > baseline clocks in at just a bit over 1GB and the "real" history set
> > (e.g. after removing all conversion artifacts) just a bit over 650MB.
> > This is the peak RSS as measurement. The 5.6 release has about half of
> > the changes, the rest will arrive with 5.7.
> >
> > (2) The phase update computation is much faster. Since that computation
> > was part of the transaction before all of the incoming data was
> > processed, it was the likely source of many of the timeouts seen in the
> > past. The changes are part of the 5.5 release.
> >
> > (3) Updates for the branchmap (e.g. what are named branches and what are
> > their heads) are computed much faster. This and a related change for the
> > topic extension are still under review. The current performance impact
> > is reasons why the non-overlay repositories (src, pkgsrc, xsrc) still
> > exists as hgweb triggers the update somewhat badly.
> 
> 
> First of all, congratulations.
> 
> I’m curious how you achieved the speed ups? Have you been hacking hg
> itself, or used some other tricks? This work would probably make a good
> story if you haven’t already considered that.

All of it so far. Some part was classic profiling to isolate hot spots
and rethinking the algorithms. Other parts are identifying what is kept
in memory longer than necessary and what can be avoided. I'll likely
write something together at some point for the techniques used.

Joerg