status performance and ... chdir

[Robert Collins]

On Wed, 2008-09-10 at 10:48 -0500, John Arbash Meinel wrote:
> 
> So... looking at these numbers, I'm guessing the overhead is in
> passing long
> paths to functions like 'open' and 'lstat'.

Traversal requires access control lookups as well as walking the
filesystem dentry cache etc. So there is a predictable overhead. I'm
amazed at how large it is though.

> I remember something similar on Mac, actually. Where the directory you
> *start*
> in, effected how long "bzr status" took.
> 
> For example, doing:
> 
> /home/jameinel/PROJECT
> 
> was measurably faster than
> /home/jameinel/work/dev/repo/PROJECT/
> 
> You might try that and see if it effects readdir w/ and w/o chdir.

My test tree is at /home/robertc/source/baz/test-repos/mozilla. So its
quite deep, and chdirring helps there; find always fchdirs, and I'm
confident its been optimised substantially :). Interesting to me would
be chdir (once) vs chdir(in and out) vs fchdir(1, 2) vs chdir to root of
tree and relpath from there scenarios.

I'm primarily interested in 'could chdiring isolated within a single
function make things slower' at this point, rather than introducing
chdiring as a library concept, because isolation is a good property to
have for a library.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080911/efb6dca7/attachment.pgp