'bzr status' stats each file multiple times

Michael Ellerman michael at ellerman.id.au
Sun Dec 4 20:14:47 GMT 2005


On Sun, 4 Dec 2005 13:41, John A Meinel wrote:
> 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?

I think it's a kludge because you're potentially losing information, ie. that 
a file has changed recently, in order to gain performance. Why 5 seconds? Why 
not 1, 10, 60, 120 ?

What I was suggesting is that we should work on the higher level code, eg. 
compare_trees() to make sure it only requires one stat per file - and 
preferably in inode order.

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/1d33fe80/attachment.pgp 


More information about the bazaar mailing list