From: Jakub Narebski Date: Wed, 06 Sep 2006 21:18:26 GMT Subject: Re: [PATCH 8/8] gitweb: Remove --parents from call to git-rev-list in parse_rev_list Message-ID: In-Reply-To: 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 -- was slightly faster than git-rev-list --full-history -- (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