Re: cloning the kernel - why long time in "Resolving 313037 deltas"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, 18 Dec 2006, Randal L. Schwartz wrote:
> 
> I have a single pack.
> 
> "Indexing" took about 30 seconds.
> "Resolving 313037 deltas" looks like it's going to take an hour.
> 
> So that *was* a local delay.

Ok, interesting. Two questions:

 - what does "top" say (is it CPU-bound? Is it perhaps blowing out your 
   disk cache? Is it swapping?)

 - do you have "oprofile" (or even just pgprof) to see where the *hell* 
   that time is spent, if it's actually CPU?

For me, it takes 25 seconds. Not an hour:

	[torvalds@woody linux]$ time git-index-pack -v -o /dev/null .git/objects/pack/*.pack
	Indexing 393507 objects.
	 100% (393507/393507) done
	Resolving 316071 deltas.
	 100% (316071/316071) done
	fatal: unable to create /dev/null: File exists
	
	real    0m24.619s
	user    0m22.569s
	sys     0m1.316s

(I admit that 25 seconds is already "too much", but it does actually end 
up exploding a lot of objects and doing quite a bit of work, so I guess 
it's fair).

And the process grew to 33MB in RSS at it's biggest, so it wasn't even 
using all that much memory (33MB isn't _tiny_, but considering that the 
pack in question is 155MB and has hundreds of thousands of objects, 33MB 
isn't really all that bad.

You're running this under OS X, aren't you? It's a pig of an OS, but 
"almost one hour" vs "25 seconds" is still unreasonable.

		Linus
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]