[Merge] performance increases for 'bzr status'

[Robert Collins]

On Tue, 2006-05-30 at 00:33 -0500, John A Meinel wrote:
...
> Honestly, I think there isn't a lot of optimization that we can do to
> file_kind at this point. What would help more would be to have a stat
> cache. I don't know how expensive it would be, but our 'is_executable'
> check does a stat, as does 'file_kind', and as does 'get_sha1' (through
> the hashcache fingerprint).
> 
> I'm not sure what the best thing would be. It might be to make
> everything go through WorkingTree, which can then maintain a cache as
> long as a lock is held. It could create in-memory inventory entries on
> demand, and they wouldn't check the on-disk files more than once.


going through workingtree ++.

I think there are some hard constraints we can state:

A 'commit foo' should:
 * stat foo and its children once only,
 * not stat any other files
 * read foo and its children only if the stat cache misses, of if their
sha differs according to the cache from their basis parent.

A 'commit' should:
 * stat $tree_root and its children once only.
 * not stat files that are not source - the fact they exist is enough to
give us unknown/ignored status.
 * read only the files whose stat cache lookups miss, or are modified
according to their hash.

Optimising of file_kind may not be needed : are we *using it* optimally?

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: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060601/a2049e44/attachment.pgp