[PATCH 4 of 6] obsolete: add native version of addsuccessors()

Martin von Zweigbergk martinvonz at google.com
Wed Feb 4 16:18:50 CST 2015


On Wed Feb 04 2015 at 2:09:25 PM Matt Mackall <mpm at selenic.com> wrote:

> On Wed, 2015-02-04 at 04:05 +0000, Martin von Zweigbergk wrote:
> > On Tue Feb 03 2015 at 8:01:14 PM Martin von Zweigbergk <
> > martinvonz at google.com> wrote:
> >
> > > # HG changeset patch
> > > # User Martin von Zweigbergk <martinvonz at google.com>
> > > # Date 1421909060 28800
> > > #      Wed Jan 21 22:44:20 2015 -0800
> > > # Node ID c6828c4acf92b415ee722371d781b28870f17e7e
> > > # Parent  cd65758885ab3cc6649001fa9aa68105d818323a
> > > obsolete: add native version of addsuccessors()
> > >
> > > This speeds up 'hg status' from 0.438s to 0.425s.
> > >
> >
> > Is this enough make it worth the extra code? I consider 3/6 worth its
> cost,
> > but I'm not sure about 4/6-6/6.
>
> One wonders why status cares about markers _at all_. Something is wrong
> here.
>
> In the past, I've considered making a bulk function 4x faster to be a
> good threshold for going to C. I think the real win here would be
> delaying actual parsing of markers into corresponding Python objects.
> This isn't smelling like a big enough win.
>
> We might want to look at duplicating the magic the index parser uses. It
> reads a whole revlog index into memory and then lazily emulates the
> Python containers we had before.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
>
Yes, I agree. I'm with with dropping these last 3 patches for now. I have a
few patches that stop 'hg status' and 'hg diff' from reading the markers,
but they're probably not the right approach.

It wasn't quite clear to me what you think about the first 3. They would
still be useful for e.g. "hg log --limit 10" or so, which does need to read
markers, but which doesn't need to populate precursors and children.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150204/d7f4942a/attachment.html>


More information about the Mercurial-devel mailing list