Nicolas Pitre wrote:
> On Sun, 10 Feb 2008, Johannes Schindelin wrote:
>
>> I tried that:
>>
>> $ git config pack.deltaCacheLimit 1
>> $ git config pack.deltaCacheSize 1
>> $ git config pack.windowMemory 2g
>
> This has nothing to do with repacking memory usage, but even tighter
> packs can be obtained with:
>
> git config repack.usedeltabaseoffset true
>
> This is not the default yet.
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).
This run took about 7 hours 26 min.
I ran: git repack -a -d -f --window=250 --depth=250
Here are the relevent config entries:
[pack]
threads = 1
compression = 9
[repack]
usedeltabaseoffset = true
Other runs:
* Same as above, but with default compression:
pack size: 1560624388
time: 7 hours 11 min
Not much difference in time or size.
* 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.
* Multi threaded (500m window)
[pack]
threads = 4
windowmemory = 500m
compression = 9
[repack]
usedeltabaseoffset = true
pack size: 1640820903
time: forgot to time, but between 3-4 hours based on file time
I just received Dscho's email, this is interesting to compare
with his single threaded result of 1638490531. I wonder if he
used deltabaseoffset? I think his machine is a little faster
than this one. So using 4 threads finished twice as fast and
produced a similar pack size. Actually, the difference could
just be the compression setting.
* Deeper (git repack -a -d -f --window=250 --depth=500)
[pack]
threads = 1
compression = 9
[repack]
usedeltabaseoffset = true
pack size: 1578263745
time: 7 hours 58 min
Larger pack compared to --depth=250.
-brandon
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
