On Wed, Oct 03, 2012 at 10:16:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
> I can't provide all the details now (not with access to that machine > now), but briefly: > > * The git client/server version is 1.7.8 > > * The repository has around 50k refs, they're "real" refs, almost all > of them (say all but 0.5k-1k) are annotated tags, the rest are > branches. I'd definitely try upgrading, then; I got measurable speedups from this exact case using the patches in v1.7.10. > * >99% of them are packed, there's a weekly cronjob that packs them > all up, there were a few newly pushed branches and tags outside of > the A few strays shouldn't make a big difference. The killer is calling open(2) 50,000 times, but having most of it packed should prevent that. I suspect Michael Haggerty's work on the ref cache may help, too (otherwise we have to try each packed ref in the filesystem to make sure nobody has written it since we packed). > * I tried "echo -n | git upload-pack <repo>" on both that 50k > repository and a repository with <100 refs, the former took around > ~1-2s to run on a 24 core box and the latter ~500ms. More cores won't help, of course, as dumping the refs is single-threaded. With v1.7.12, my ~400K test repository takes about 0.8s to run (on my 2-year-old 1.8 GHz i7, though it is probably turbo-boosting to 3 GHz). So I'm surprised it is so slow. Your 100-ref case is slow, too. Upload-pack's initial advertisement on my linux-2.6 repository (without about 900 refs) is more like 20ms. I'd > * A co-worker who was working on this today tried it on 1.7.12 and > claimed that it had the same performance characteristics. That's surprising to me. Can you try to verify those numbers? > * I tried to profile it under gcc -pg && echo -n | ./git-upload-pack > <repo> but it doesn't produce a profile like that, presumably > because the process exits unsuccessfully. If it's a recent version of Linux, you'll get much nicer results with perf. Here's what my 400K-ref case looks like: $ time echo 0000 | perf record git-upload-pack . >/dev/null real 0m0.808s user 0m0.660s sys 0m0.136s $ perf report | grep -v ^# | head 11.40% git-upload-pack libc-2.13.so [.] vfprintf 9.70% git-upload-pack git-upload-pack [.] find_pack_entry_one 7.64% git-upload-pack git-upload-pack [.] check_refname_format 6.81% git-upload-pack libc-2.13.so [.] __memcmp_sse4_1 5.79% git-upload-pack libc-2.13.so [.] getenv 4.20% git-upload-pack libc-2.13.so [.] __strlen_sse42 3.72% git-upload-pack git-upload-pack [.] ref_entry_cmp_sslice 3.15% git-upload-pack git-upload-pack [.] read_packed_refs 2.65% git-upload-pack git-upload-pack [.] sha1_to_hex 2.44% git-upload-pack libc-2.13.so [.] _IO_default_xsputn So nothing too surprising, though there is some room for improvement (e.g., it looks like we are calling getenv in a tight loop, which could be hoisted out to a single call). Do note that this version of git was compiled with -O3. Compiling with -O0 produces very different results (it's more like 1.3s, and the hotspots are check_refname_component and sha1_to_hex). > Maybe someone here knows offhand what mock data I could feed > git-upload-pack to make it happy to just list the refs, or better > yet do a bit more work which it would do if it were actually doing > the fetch (I suppose I could just do a fetch, but I wanted to do > this from a locally compiled checkout). If you feed "0000" as I did above, that is the flush signal for "I have no more lines to send you", which means that we are not actually fetching anything. I.e., this is the exact same conversation a no-op "git fetch" would produce. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
