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

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

 



On Dec 18, 2006, at 18:02:07, Martin Langhoff wrote:
On 18 Dec 2006 14:26:36 -0800, Randal L. Schwartz <merlyn@xxxxxxxxxxxxxx> wrote:
Linus Torvalds wrote:
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.

I agree!

Me too -- but entirely possible. Disk IO is specially painful on OSX. Stat calls are horrid. Using Arch (which abused stat calls to no end) many ops would take 50x-100x longer on OSX than on Linux. A large unpacked repo with git is a real pain -- and packing it can take hours.

I've actually also seen filesystem operation latency double or triple if you start trying to do operations from multiple threads at once. Suddenly the already dog-slow single-CPU operations start bouncing caches and the Mac OS X mostly-whole-of-BSD-BKL across CPUs and it just crawls. I can definitely see the local disk IO taking 100x longer than the network I/O, especially with an 8-megabit internet link.

Once you are packed it's sweet, but large repos are a pain to deal with. You won't impress anyone with performance over a linux kernel repo -- starting up gitk can take a long time. Stat-heavy stuff like git-diff is noticeably slower under OSX.

Just as an example, it takes my OS-X-running Quad-2.5GHz G5 ten times as long to do a "grep -rl foo linux/" as my Linux-running dual-1GHz G4 with 400MHz system bus. This is disk-cache-hot too. And that's not even a stat-heavy workload. There's more than one reason I'm trying to make a Mac OS X ABI emulation layer on top of Linux :-D.

Cheers,
Kyle Moffett

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