That's an interesting test-case (and I get 53 seconds, nyaah, nyaah ;)
However, it's almost totally *not* about object access any more with my
patches. All the top profiling hits are about generating the patches and
assigning blame:
samples % image name app name symbol name
470352 15.5813 git git xdl_hash_record
298683 9.8944 git git cmp_suspect
225156 7.4587 git git assign_blame
221308 7.3312 libc-2.5.so libc-2.5.so memcpy
177621 5.8840 libc-2.5.so libc-2.5.so memchr
163571 5.4186 vmlinux vmlinux __copy_user_nocache
129301 4.2833 git git xdl_prepare_ctx
99009 3.2799 libc-2.5.so libc-2.5.so _int_malloc
83899 2.7793 git git xdiff_outf
80588 2.6696 libz.so.1.2.3 libz.so.1.2.3 (no symbols)
..
so as you can see, libz is down in the 2.5% range, and strlen and the tree
accessor functions are totally un the noise.
So it looks like it *used* to be somewhat of a problem (the object access
itself must have been about 10 seconds, since that got shaved off the
time), but realistically, if you want to speed up "git blame", we can
totally ignore the git object data structures, an dconcentrate on xdiff
and on blame itself (cmp_suspect and assign_blame probably have some nasty
O(n^2) behaviour or something like that, that could hopefully be fixed
fairly easily. The xdl hashing is a different thing, and I don't think
it's necessarily easy to fix that one..)
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
