From: Ben Peart Date: Fri, 17 Aug 2018 12:37:03 GMT Subject: Re: [PATCH v3] checkout: optimize "git checkout -b " Message-ID: <448bd740-73fb-aa3a-ded0-e4012cf6ec21@gmail.com> In-Reply-To: On 8/16/2018 2:37 PM, Duy Nguyen wrote: > On Thu, Aug 16, 2018 at 8:27 PM Ben Peart wrote: >> >> From: Ben Peart >> >> Skip merging the commit, updating the index and working directory if and >> only if we are creating a new branch via "git checkout -b ." >> 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 " 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. >