Re: [PATCH 8/8] gitweb: Remove --parents from call to git-rev-list in parse_rev_list

Linus Torvalds wrote:

On Wed, 6 Sep 2006, Jakub Narebski wrote:

quoted

Benchmarks (7 means patch before, 8 means this patch):

Btw, you should possibly look at cold-cache numbers, and numbers for 
projects that aren't fully packed. They can often be _dramatically_ 
different.

By the way I forgot that the case 8 is for the repository with 1 commit
more, although that shouldn't matter much for paginated output. Still, it
is one commit more unpacked. Benchmark for 7 was also for partially packed
repository.
 

That said, the dramatic change would probably be if there were some way to 
avoid using "--full-history" (rather than "--parents", which doesn't add 
_that_ much overhead), since that "follow all parents" behaviour of 
full-history is usually what really makes a big deal.

But I guess for gitweb, you do want to use --full-history in this case ;(

It is now easy with patch 3/7 "Use @hist_opts as git-rev-list parameters in
git_history" to remove '--full-history' from git-rev-list parameters in
git_history subroutine. Or add '--remove-empty' which matters only for the
last page of file/directory history output.

I had some simple benchmark that shown that the earlier version with
filtering via piping git-rev-list to git-diff-tree --stdin -- <filename>
was slightly faster than git-rev-list --full-history -- <filename>
(current version). If I remember correctly of course. And this version can
be easily extended to include renames (but not file to directory changes).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git