'bzr status' stats each file multiple times

[John A Meinel]

Michael Ellerman wrote:
> 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.

How is it a kludge? Isn't it exactly what you just requested. Stat
everything 1 time?
It is actually a slight benefit on top of it, which says that you can
respect that something might change while you're working, so you will
expire entries after a while.

It might be fancier than is really needed. We could certainly just cache
all of the stat entries.

What if you simplify it to say, "If I have statted this file within the
last 5 seconds, don't stat it again".

Though I'm still tempted to say, "If I've statted the file within the
last 5 seconds, and it more than 5 seconds old, don't stat it again"

John
=:->

> 
> cheers
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051204/2221040d/attachment.pgp