Linus Torvalds wrote: > On Wed, 6 Sep 2006, Jakub Narebski wrote: >> >> 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 - 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