Re: Trac+Git: rev-list with pathspec performance?

[Jakub Narebski <jnareb@gmail.com>]

Stephen Bash <bash@genarts.com> writes:

> I'm trying to improve the performance of Trac [1], the GitPlugin for
> Trac[2], and Git.  Trac is being extremely sluggish while browsing
> source, and profiling revealed the majority of the time was the
> GitPlugin calling git rev-list.  When I directly entered the
> rev-list calls from the shell, I found Git itself was performing
> slower than I would expect...
> 
> The bottleneck is while Trac is populating the "last change to file"
> column in the source browser (see the "rev" column of [3] for an
> *cough* SVN *cough* example).  This concept of "find the last change
> to a file" was discussed a few weeks ago [4], but unlike that
> thread, the GitPlugin is simply calling git rev-list --max-count=1
> branchName -- fileName for each file in the current directory.  For
> files modified recently this is very fast (thousandths of a second),
> but for older files rev-list takes a long time to come up with an
> answer (~2-3 seconds on our server).
[...]

> References:
> [1] http://trac.edgewall.org
> [2] http://trac-hacks.org/wiki/GitPlugin
> [3] http://trac.edgewall.org/browser/trunk
> [4] http://article.gmane.org/gmane.comp.version-control.git/150183/

Note that later[5] in mentioned thread[4] there is proof of concept
"tree blame" (in Perl) which generates such 'last change to file'
information, I think faster than running 'git rev-list -1 <file>' for
each file.  Even better would be to encode used algorithm in C.

[5] http://thread.gmane.org/gmane.comp.version-control.git/150063/focus=150183

P.S. Alternate solution would be to simply get rid of SVN-inspired
view.  Git tracks history of a *project* as a whole, not set of
histories for individual files (like CVS).

-- 
Jakub Narebski
Poland
ShadeHawk on #git