Re: [RFC] Introducing different handling for small/large transactions
- From
Jeff King <peff@peff.net>
- Date
- Jan 15, 2015, 22:46 UTC
- Message-ID
- <20150115224605.GD19021@peff.net>
- In-Reply-To
- <1421361371-30221-1-git-send-email-sbeller@google.com>
On Thu, Jan 15, 2015 at 02:36:11PM -0800, Stefan Beller wrote:
> So for here is my proposal for small transactions: > (just one ref [and/or reflog] touched):
The implication being that a "large" transaction is any with more than one update.
I think performance may suffer if you do not also take into account the size of the packed-refs file. If you are updating 5 refs and there are 10 in the packed-refs file, rewriting the extra 5 is probably not a big deal. If there are 400,000 in the packed-refs file, it probably is. I'm not sure where the cutoff is (certainly the per-ref cost is less for packed-refs once you have started writing the file, so there is probably some crossover percentage that you could measure).
Show 9 quoted lines
> * detect if we transition to a large transaction > (by having more than one entry in transaction->updates) > if so: > * Pack all currently existing refs into the packed > refs file, commit the packed refs file and delete > all loose refs. This will avoid (d/f) conflicts. > > * Keep the packed-refs file locked and move the first > transaction update into the packed-refs.lock file
This increases lock contention, as now independent ref updates all need to take the same packed-refs.lock. This can be a problem on a busy repository, especially because we never retry the packed-refs lock. We already see this problem somewhat on GitHub. Ref deletions need the packed-refs.lock file, which can conflict with another deletion, or with running `git pack-refs`.
-Peff