On Thu, 14 Feb 2008, Brandon Casey wrote:

quoted text
> I have successfully repacked this repo a few times on a 2.1GHz system 
> with 16G.
> 
> The smallest attained pack was about 1.45G (1556569742B).
> 
[...]
quoted text
> 
> * Multi threaded (250m window)
> [pack]
>         threads = 4
>         windowmemory = 250m
>         compression = 9
> [repack]
>         usedeltabaseoffset = true
> 
> 	pack size: 1767405703
> 	time: 3 hours
> 
> 	First >99% took 50min. Last 10000 objects took 2hours.

Right.  That's because the algorithm to distribute the load between 
threads ends up stealing work from other threads whenever a thread is 
done with its own share.  So the easy objects are quickly done with by a 
few threads until they all converge onto the hard ones.  In the non 
threaded case, the slow down ocurs around 12%.

It looks like those hard objects are huge binary blobs.  If they could 
be removed from the repository entirely and regenerated as needed 
instead of being carried around then I expect the repository size would 
fall below the 500MB mark.


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