Thread (31 messages) flat view 31 messages, 12 authors, 2016-08-11

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

From: Kyle Moffett <hidden>
Date: 2016-06-15 22:42:46

Possibly related (same subject, not in this thread)

On Dec 18, 2006, at 18:02:07, Martin Langhoff wrote:
On 18 Dec 2006 14:26:36 -0800, Randal L. Schwartz  
[off-list ref] wrote:
quoted
Linus Torvalds wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help