Re: [PATCH 3/2] Avoid unnecessary strlen() calls

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sun, 18 Mar 2007, Junio C Hamano wrote:
> 
> 	git blame -C block/ll_rw_blk.c
> 
> Just for fun, these are the same for the kernel history with tglx-history 
> repository's history grafted behind it, i.e. with this grafts file:
> 
> $ cat .git/info/grafts
> 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 e7e173af42dbf37b1d946f9ee00219cb3b2bea6a
> 
> (v1.5.0)
> 73.80user 2.57system 1:16.40elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+773077minor)pagefaults 0swaps
> 
> (master + three patches)
> 65.14user 0.40system 1:05.55elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+125052minor)pagefaults 0swaps
> 
> In either case, it is showing drastic reduction of minor faults.

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