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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:00:39 EST