Stephen Bash <bash@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html