On Tue, Aug 28, 2012 at 04:39:11PM -0700, Junio C Hamano wrote:
> > git rev-list --committer=torva...@linux-foundation.org \
> > --max-parents=2 --min-parents=2 --parents v3.5..v3.6-rc2 >RL
> > cmd='
> > while read result parent1 parent2
> > do
> > $GIT merge-base $parent1 $parent2
> > done <RL
> > '
> I have this suspicion that it is spending most of its time in
> insert-by-date. Luckily, merge_bases_many() is totally outside of
> the usual revision traversal and its use of the commit list is
> pretty well isolated.
> Peff, can I interest you into resurrecting your $gmane/174007 and
> $gmane/174008 (we do not need pop_commit_from_queue() in the latter;
> everything can stay as static to commit.c for now) to see how well
> priority queue based approach would perform?
I did a quick port of merge_bases_many and get_merge_bases_many to use
priority queues, but I didn't see any speedup at all on the above test
case. According to perf, we spend most of our time in zlib, inflating
commits. Only 1% is spent on commit_list_insert_by_date, which is about
the same amount spent on queue insertion after my patches.
Patches follow, just for reference.
[1/2]: basic priority queue implementation
[2/2]: commit: use a priority queue in merge base functions
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html