On Thu, 6 Sep 2007, Junio C Hamano wrote:

quoted text
> Nicolas Pitre <nico@cam.org> writes:
> 
> > this is still rough, hence it is disabled by default.  You need to compile
> > with "make THREADED_DELTA_SEARCH=1 ..." at the moment.
> >
> > Threading is done on different portions of the object list to be
> > deltified. This is currently done by spliting the list into n parts and
> > then a thread is spawned for each of them.  A better method would consist
> > of spliting the list into more smaller parts and have the n threads
> > pick the next part available.
> 
> Hmmm.  I wonder how the result is affected by such a partition;
> aren't you going to have many objects that could have used
> somebody else as a delta but gets stored as base because they
> happen to be a very early part of their partition (and lacking
> delta base candidates in the window)?  

Yes.  On a largish repo that shouldn't be significant though, not worse 
than repacking multiple packs into one without -f.

quoted text
> You cannot solve it with
> overlapping partitions without busting the depth limit easily
> either, I suspect.

My plan is to call find_deltas() again over partition boundaries after 
adjacent partitions have been processed.  If delta_child is properly 
maintained in all cases (trivial) then this should just work.

quoted text
> Also how would this interact with the LRU
> delta base window we discussed a week or two ago?

This is completely orthogonal.

quoted text
> Separating the list into different object types would not have
> any adverse impact coming from the "horizon" of delta base
> candidates window (because we do not deltify across types), but
> that is not very useful because we cannot gain much parallerism
> from such a partition.

Indeed.  Even with a straight split with equal number of objects, some 
threads currently complete much faster than others.  This is why a more 
sophisticated distribution of work is still needed to keep the desired 
amount of threads busy all the time.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html