Re: #include_next and absolute pathnames

[kaih at khms dot westfalen dot de (Kai Henningsen)]

zack at codesourcery dot com (Zack Weinberg)  wrote on 03.03.03 in <87heakorie dot fsf at egil dot codesourcery dot com>:

> Geoff Keating <geoffk at geoffk dot org> writes:

> > Yup.  I'm not sure where the threshold will be, that'll have to wait
> > on timing numbers when I finally get a patch.  I think timing results
> > on the local version of the patch found that readdir() didn't hurt
> > even "hello-world" programs.
>
> Interesting.  I'd like to see data taken on multiple platforms; I bet
> this is highly OS- and libc-dependent.  (Happy to help with testing.)

Well, consider that IF your readdir() implementation is reasonable, and  
your filesystem a typical (non-indexed) Unix filesystem, then readdir()ing  
a directory should be about as expensive as a failed lookup of a file in  
that directory - both need to read the whole directory once, and nothing  
else.

The moment you need to know about the second file in the same directory,  
you should win.

Note, however, that this is certainly wrong if your directory already has  
some sort of index (making a failed lookup vastly faster), or if your  
readdir() is not a reasonably shallow layer on scanning for the right name  
(for example, if it does the equivalent of stat() for each file).

So it may well be that this is a big win on Linux with ext2 (say), and a  
big loss on Cygwin. (I'm not claiming that it will necessarily be the  
case, just pointing out that there's something to watch for.)

Of course, what is "a typical real-life project" is also different for  
different users. It might be necessary (though it would certainly better  
if that could be avoided) to control this via runtime options.

MfG Kai