Re: [PATCH v3] checkout: optimize "git checkout -b <new_branch>"
- From
Ben Peart <peartben@gmail.com>
- Date
- Aug 17, 2018, 12:37 UTC
- Message-ID
- <448bd740-73fb-aa3a-ded0-e4012cf6ec21@gmail.com>
- In-Reply-To
- <CACsJy8B84T9HSJKAErNAyoMwbBpu6Gwgyz3RsvmqD0+o=bg3Ng@mail.gmail.com>
On 8/16/2018 2:37 PM, Duy Nguyen wrote:
Show 27 quoted lines
> 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. >