Re: [PATCH v3] checkout: optimize "git checkout -b <new_branch>"

[Ben Peart <peartben@gmail.com>]

On 8/16/2018 2:37 PM, Duy Nguyen wrote:
> On Thu, Aug 16, 2018 at 8:27 PM Ben Peart <Ben.Peart@microsoft.com> wrote:
>>
>> From: Ben Peart <Ben.Peart@microsoft.com>
>>
>> Skip merging the commit, updating the index and working directory if and
>> only if we are creating a new branch via "git checkout -b <new_branch>."
>> Any other checkout options will still go through the former code path.
>>
>> If sparse_checkout is on, require the user to manually opt in to this
>> optimzed behavior by setting the config setting checkout.optimizeNewBranch
>> to true as we will no longer update the skip-worktree bit in the index, nor
>> add/remove files in the working directory to reflect the current sparse
>> checkout settings.
>>
>> For comparison, running "git checkout -b <new_branch>" on a large repo takes:
>>
>> 14.6 seconds - without this patch
>> 0.3 seconds - with this patch
> 
> I still don't think we should do this. If you want lightning fast
> branch creation, just use 'git branch'. From the timing breakdown you
> shown in the other thread it looks like sparse checkout still takes
> seconds, which could be optimized (or even excluded, I mentioned this
> too). And split index (or something similar if you can't use it) would
> give you saving across the board. There is still one idea Elijah gave
> me that should further lower traverse_trees()  cost.
> 

We have investigated some of these already - split index ended up 
slowing things down more than it sped them up do to the higher compute 
costs.  Sparse checkout we've already optimized significantly - limiting 
the patterns we accept so that we can do the lookup via a hashmap 
instead of the robust pattern matching.  We will continue to look for 
other optimizations and appreciate any and all ideas!

In the end, this optimization makes a huge performance improvement by 
avoiding doing a lot of work that isn't necessary.  Taking a command 
from 14+ seconds to sub-second is just too much of a win for us to ignore.

> But anyway, it's not my call. I'll stop here.
>