On Fri, 10 Jul 2009, Paolo Bonzini wrote: > > I'm not much worried about accessing foo-0001, foo-0002, foo-0003 while > looking for foo/a (that would be O(number of files in a directory), > which is bearable), but risking to go down a huge subtree is not very > nice. That sounds rather unlikely, and the thing is, even if it were to happen, it really wouldn't be that slow. Our data structures are pretty efficient, and it wouldn't be _that_ slow to traverse them. That said, I don't love that loop. It would be better to do that whole cache_name_pos() call with the '/' simply appended to the path, and then we'd do the binary search directly to the first entry. Of course, since 'path' is a 'const char *', we'd need to either do a silly copy, or we'd need to change a whole lot of the code to make it clear that we can actually add a slash to the end (which we can: I think it's already always going to be an array that we _will_ add a slash to in case it turns out to be a directory). So there's definitely room for improvement there. I just think that the improvement isn't the patch you suggest. 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