Re: git blame performance

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 6, 2015, 17:53 UTC
Message-ID: <xmqqwptv2eve.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <563CBEC8.7070209@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 15 quoted lines

> The reason that cvs annotate is so much faster than git blame is that
> CVS stores revisions filewise, with all of the modifications to file
> $FILE being stored in a single $FILE,v file. So in the worst case, CVS
> only has to read this one file.
>
> Git, on the other hand, stores revisions treewise. It has no way of
> knowing, ab initio, which revisions touched a given file. (In fact, this
> concept is not even well-defined because the answer depends on things
> like whether copy (-C) and move (-M) detection are turned on and what
> parameters they were given.) This means that git blame has to traverse
> most of history to find the commits that touched $FILE.
>
> Slow git blame is thus a relatively unavoidable consequence of Git's
> data model. That's not to say that it can't be sped up somewhat, but it
> will never reach CVS speeds.

Another thing to consider for a converted repository is that mass converters tend to either not make a pack at all or make a pack that is horribly inefficient to access. Running "git repack -a -d -f" with a small value of "--depth" may be a thing worth trying, if that is contributing to the performance.