Re: [ACPI] ACPI mentioned on lwn.net/kernel

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

Alexander Viro wrote:
> Most likely it says very bad things about getcwd() implementation in Perl
> compared to sys_getcwd() in the kernel.  The latter just walks the chain
> of dentries copying ->d_name.name into the buffer.  The former... my guess
> would be stat ".", open "..", readdir from it, stat every damn object in
> there until you find one with the right ->st_ino, put its name as the
> last component and repeat the whole thing until you reach root...

I better correct my statement.  Just had a look at the old Perl script
in question.

I was originally using 'use Cwd; getcwd()'.  That was really slow and it
does exactly what Alex says.  Even though you don't need to call stat()
on each entry: the readdir system call returns the inode numbers for all
directories that aren't mount points, but Perl doesn't give that
information to its libraries (for the sake of portability).

Then I switched to 'use POSIX; getcwd()'.  That was faster, but still
distressingly slow (i.e. noticable in human terms).  POSIX::getcwd()
forks and execs to call /bin/pwd, and is quite fast.  But 'use POSIX' is
quite slow.  Shame really, because the implementation is in a shared
library; it's just the 'use POSIX' importing part that's slow.

Then I tried `/bin/pwd' myself since the POSIX function uses it.  That
was pretty fast and I was impressed with Linux for being that fast.  Of
course it is still 1.7 million cycles which is not brilliant, but it was
faster than I'd expected for a pipe/fork/exec.

Finally I just did the getcwd() system call myself.  Used a hard-coded
system call number, because reading it from a header file was slow.
Linus was right about startup times in this case.

enjoy,
-- Jamie