Re: [PATCH 4/3] Avoid using 'lstat()' to figure out directories

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 9, 2009, 23:26 UTC
Message-ID: <alpine.LFD.2.01.0907091626080.3352@localhost.localdomain>
In-Reply-To: <4A5670F3.9020309@gnu.org>

On Fri, 10 Jul 2009, Paolo Bonzini wrote:

Show 5 quoted lines

> 
> 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