This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -remap: Should we remap before / after simplification?
On Fri, Mar 16, 2001 at 07:38:57AM -0800, H . J . Lu wrote:
> On Fri, Mar 16, 2001 at 03:14:46PM +0100, Gerald Pfeifer wrote:
> > On Thu, 15 Mar 2001, Zack Weinberg wrote:
> > > I will not support any change which is a performance improvement on
> > > Linux and a lose on just about every other system in existence. (Do
> > > recent BSDs have getcwd(2)?)
> >
> > You mean getcwd(3), right?
>
> I think Zack did mean getcwd(2). Linux has system call support for
> getcwd.
Right. With a pathname cache, you can implement getcwd in-kernel and
make it be much, much faster than the user space implementation.
Among many other benefits.
I dug through freebsd.org's CVSweb for a bit, and it turns out that
they do have kernel support for getcwd, and a pathname cache. I can't
tell if the pathname cache is as pervasive as the one in Linux, but it
probably wouldn't need to be that pervasive to get 90+% of the
performance wins. __getcwd(2) was added in late 1999 - I don't know
how that translates to release numbers.
Empirically speaking, I spent a short time as a build monkey for a
commercial software house. They did builds on: Linux 2.2, FreeBSD
4.x, Digital UNIX 4.x, Solaris 2.5, HP/UX 10.x, AIX 4.1; all with
roughly equivalent hardware and the exact same compiler (egcs 1.1,
IIRC). Wall time to complete builds went like this:
Linux ~ FreeBSD >> DUnix ~ Solaris >> HP/UX >> AIX
with the builds at the far right being painfully slow, and the ones at
the far left taking only a couple minutes.
Since we're arguing about ways to speed up #include anyway, how's
about this idea: hold open each directory in the search path, and
fchdir() to it to open files relative to it. It would probably be
only a small win, because systems with fchdir() are likely to have
some sort of namei cache anyway. But maybe not - look at Solaris.
zw