'bzr status' stats each file multiple times

[Michael Ellerman]

On Sun, 4 Dec 2005 08:43, John A Meinel wrote:
> The idea of calling hashcache.scan() early, is that you can stat in
> inode order. Which according to git, should be faster. And who would
> know better than kernel hackers. :)

OK that sounds reasonable, except that we then re-stat everything. So that's 
two stats for every file in the cache right there, sounds look a false 
optimisation to me.

If we're interested in being really fast, then we should do the entire status 
operation in inode order - we can sort the output if we want to. But step one 
should be to make sure status only stats each file exactly once.

> I think we should have a timeout value. So that if I stat'd the file
> within the last X seconds, I assume the file hasn't changed.
> We can even go one better, and do a double check saying, If the files
> mtime is older than Y seconds, and I have stat'd the file within X
> seconds, don't stat again.

Hmm, that sounds like a kludge to me - I think we can improve on the current 
times before we need to resort to something like that.

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051204/0e2467b0/attachment.pgp