Re: Debugging git-commit slowness on a large repo
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 5, 2011, 17:38 UTC
- Message-ID
- <7vr50inckx.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20111203002347.GB2950@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
Show 9 quoted lines
> ... At one > point, commit forgot how to write the tree cache to the index (a > performance optimisation). Do the times improve if you run 'git > read-tree HEAD' between one commit and another? Note that this will > reset the index to the last commit, though for the tests I image you > use some variation of 'git commit -a'. > > Thomas Rast wrote a patch to re-teach commit to store the tree cache, > but there were some issues and never got applied.
Ahh, I forgot all about that exchange.
http://thread.gmane.org/gmane.comp.version-control.git/178480/focus=178515
The cache-tree mechanism has traditionally been one of the more important optimizations and it would be very nice if we can resurrect the behaviour for "git commit" too.