Re: [PATCH 2/2] Implement a simple delta_base cache

On Sat, 17 Mar 2007, Linus Torvalds wrote:

quoted

That's a lot of strings, or perhaps very long strings.  Or a profiling bug.

Btw, the reason I'm pretty sure that it's not a profiling bug is that
 (a) the rest of the profile looks fine
 (b) it actually matches the rest of the profile.

In particular, while you reacted to

	samples  %        app name                 symbol name
	41527    15.6550  git                      strlen

you didn't bat an eye on

	9240      3.4833  git                      get_mode
	8863      3.3412  git                      tree_entry_extract

ie over 3% of time spent in tree entry extract and get_mode. But take 
another look at that tree_entry_extract() function in particular and look 
what it does, and ask yourself: if *that* function takes up 3% of time, 
what does it tell you about strlen()?

(Side note: we could probably improve "strlen()" in particular. We 
sometimes call it twice: look at "entry_extract()", which calls strlen() 
on the tree entry extract, but then *also* calls strlen on the resulting 
path.

I suspect the

	a->pathlen = strlen(a->path);

could be written as

	a->pathlen = (char *)a->sha1 - (char *)a->path - 1;

but somebody should check that I didn't off-by-one or something. Also, it 
migt be better to make that part of "tree_entry_extract()" itself, because 
other callers do the same thing (see "find_tree_entry()": doing a 
"strlen()" on the path return of tree_entry_extract() seems to be a common 
pattern).

HOWEVER!

Once we get to *that* level of optimizations, we're doing pretty damn 
well. I'm sure we could probably cut down that strlen() from 16% to 8% by 
being smart about it, but still - this is a "good kind of problem" to 
have, if these things are your lowest-hanging fruit!

Maybe it all boils down to the same thing: I just can't seem to be really 
upset about "git log drivers/usb/ > /dev/null" taking all of a second. It 
just doesn't strike me as a performance problem ;)

			Linus