Re: pack-object poor performance (with large number of objects?)

From: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
Date: Oct 4, 2011, 07:59 UTC
Message-ID: <CAA01CsoSTsBLNcbv5o6Jx6YrjG4g8T=yodX811ymBLXg7sjDJQ@mail.gmail.com>
In-Reply-To: <7v62k5g988.fsf@alter.siamese.dyndns.org>

On Mon, Oct 3, 2011 at 9:34 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

> This is on my box [*1*] that is idle (other than running the repack). The
> above is starting from an already reasonably well packed state and reuses
> deltas; with "-f" to repack everything from scratch it would take
> significantly longer:
>
>    linux-3.0/master$ time git repack -a -d -f
>    Counting objects: 2138578, done.
>    Delta compression using up to 4 threads.
>    Compressing objects: 100% (2118691/2118691), done.
>    Writing objects: 100% (2138578/2138578), done.
>    Total 2138578 (delta 1749156), reused 344219 (delta 0)
>
>    real    3m26.750s
>    user    8m41.857s
>    sys     0m6.716s

I've run the command and it took about 20 minutes in "Counting objects" to count up to 500000 on idle machine and there's still 700MB RAM free.

I wonder, when you do the repacking from a packed state, does it physically create files on file system? In my case I have lots of files in objects dir:

$ ls objects/ | wc -l 258 $ ls objects/00 | wc -l 6173

When I tried 'find objects | wc -l' previously (when repack was not running) it got "stuck" too and I got impatient and killed it ;)

So it looks it's not a problem with git but rather with my disk/file system/linux...

-- 
Piotr Krukowiecki