On Sat, 17 Mar 2007, Linus Torvalds wrote: > > > > 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 - 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