Re: Cloning speed comparison

Daniel Barkalow [off-list ref] writes:

I should be able to get http-pull down to the neighborhood of 
(current) ssh-pull; http-pull is that slow (when the source repository 
isn't packed) because it's entirely sequential, rather than overlapping 
requests like ssh-pull now does.

I like those prefetch() and process() code in pull.c very much.

I have been wondering if increasing parallelism more by
prefetching beyond the immediate parents of the current commit,
in "if (get_history)" part of process_commit().  Maybe it is not
worth it because doing a commit, its associated tree(s) and its
parents would already give us enough parallelism already.

(I've written an untested patch for local-pull, which I'll be testing, 
cleaning, and submitting tonight, assuming my newly-arrived monitor 
actually works)

That is a great news.  Thank you for doing this; looking forward
to see it, but no rush.  Enjoy your new monitor.

On Mon, 15 Aug 2005, Junio C Hamano wrote:

Daniel Barkalow [off-list ref] writes:

quoted

I should be able to get http-pull down to the neighborhood of 
(current) ssh-pull; http-pull is that slow (when the source repository 
isn't packed) because it's entirely sequential, rather than overlapping 
requests like ssh-pull now does.

I like those prefetch() and process() code in pull.c very much.

I have been wondering if increasing parallelism more by
prefetching beyond the immediate parents of the current commit,
in "if (get_history)" part of process_commit().  Maybe it is not
worth it because doing a commit, its associated tree(s) and its
parents would already give us enough parallelism already.

It is actually already maxing out the parallelism; it has a FIFO of 
objects which it needs, and calls prefetch() when it enqueues an object 
and fetch() when it dequeues it. It only cares about the dependancies for 
this purpose, not the types.

	-Daniel
*This .sig left intentionally blank*