[MERGE][#230567] Faster (local) branch

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> I'm also not building inventory entries - I'm using the entries from the
> source inventory instead. Again, that's only possible when the tree is
> being created from scratch.

That's true.  Do you think that's a significant factor in branch
creation speed?  It only shows up at 0.84 ticks in the data you supplied.

> I'll take a fresh look at how I can make the single codepath faster.
> Having said that, I'd like to request that we keep an open mind about
> multiple code paths here.

Sure.  But similarly, I'd like to request that we keep an open mind
about the size of change that's needed to bring those benefits.

> The faster code path I've introduced will
> apply to 100% of branch commands and almost 100% of checkout commands.

Right.  But the speedups you've identified so far seem like they could
be applied to 100% of tree manipulation commands, i.e. checkout, revert,
merge branch, pull...

> *One* way to get a single code path is to drop support for checkout
> into a directory already containing files. :-)

Would that actually help?  It seems like the code we could drop would be
code that is necessary for all the other operations that single codepath
must support.

> I'm also not convinced that branch/checkout should be treated as
> special cases of merge/revert w.r.t. internal logic.

Neither am I.  If you can suggest enhancements that couldn't plausibly
be done as part of the current codepath, I'll gladly discuss how to
implement them.

> It's perfectly
> acceptable IMO to maximise the code resuse but a 50-60% performance
> hit for doing so unnecessarily isn't justified.

What is your basis for suggesting that this would incur a 50-60%
performance hit?

> In fact, I suspect
> there's even more room for making the 'create from scratch' code path
> faster still, e.g. coping across the dirstate from the source tree
> instead of building it from scratch

I hope you'll forgive me if the thought makes me cringe.  Yes, I know
that we'll have verified that the source is pristine by that point.

> To put some context around this work, it's been bugging me for some
> time that our local branching isn't faster.

If my efforts thus far have proved inadequate, it's not for lack of trying.

> If we're serious about
> performance, we ought to be taking those sorts of gains IMO by using
> a faster code path, particularly if it applies in the majority of
> cases as this one does.

Stop it, Ian.  Don't get stuck on your first idea.  If there really are
enhancements we can't achieve with a single codepath, I will support
that kind of change.  But in order to convince me, you are going to have
to tell me what they are.  If there aren't any, then it is wasteful to
have more than one codepath.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIP19j0F+nu1YWqI0RAoHkAJ41mKIaFhS514kMtJdlb3M/ymeUYwCdHuQJ
vEDfy8+HPMfNZmxx99CIX2M=
=r0Mj
-----END PGP SIGNATURE-----