On Sat, 25 Jul 2009, Carlos R. Mafra wrote: > > Ok, so I killed /usr/sbin/preload and did the tests again. The > results were much more stable, with average 0.40 vs 0.79 > (NO_CURL=1 being faster). The pagefaults were pretty stable too, > (40major+654minor vs 12major+401minor). > > I will use NO_CURL=1 from now on! I actually find it interesting that this whole NO_CURL issue is actually a lot more noticeable for me in the hot-cache case than all the other 'git branch' issues were. I went back to a version a few days ago (before all the optimizations), and on my machine with a hot cache I get (for my kernel repo - I don't use branches there, but I have an old 'akpm' branch for taking a emailed patch series from Andrew): [torvalds@nehalem linux]$ time ~/git/git branch akpm * master real 0m0.005s user 0m0.004s sys 0m0.000s so it's five milliseconds. Big deal, fast enough, right? Ok, so fast-forward to today, with the optimizations to builtin-branch.c: [torvalds@nehalem linux]$ time ~/git/git branch akpm * master real 0m0.004s user 0m0.000s sys 0m0.004s Woot! I shaved a millisecond off it by avoiding all those page faults and object lookups. Good, but hey, all that unnecessary lookup was just a 25% cost. So let's build it with NO_CURL: [torvalds@nehalem linux]$ time ~/git/git branch akpm * master real 0m0.002s user 0m0.000s sys 0m0.000s Heh. The whole NO_CURL=1 thing is actually a _bigger_ optimization than anything else I did to git-branch. Cost of curl: 100%. The difference in number of system calls and page faults is really quite staggering. System calls: 397->184, page faults: 619->293. Just from not doing that curl loading. No wonder performance actually doubles. Now, I admit that 5ms vs 2ms probably doesn't really matter much, but dang, performance was a primary goal in git, so I'm a bit upset at how bad curl screwed us. Plus those things do add up when scripting things, and those 300+ page faults are basically true for _all_ git programs. So it's not just 'git branch': doing 'git show' shows the exact same thing: 6ms -> 4ms, 448->235 system calls, and 1549->1176 page faults. So curl really must die. It may not matter for the expensive operations, but a lot of scripting is about running all those "cheap" things that just add up over time. 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