[RFC] question about different behavior of WorkingTree.iter_changes

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Belchenko wrote:
> I'm working hard to finish my line-endings support work ASAP.
> With my eol changes (running from python sources):
> 
> python bzr --no-plugins --no-aliases st
> time: 1.656 sec.
> 
> python bzr --no-plugins --no-aliases st -S
> time: 5.828 sec.
> 
> This difference seems a bit TOO much. Something really wrong here.
> Can somebody give me a hint why it behaves *so* different?

I haven't had a chance to look at this, but Bazaar has profiling support
built-in, with the --lsprof flag.  This can help you track down
performance problems.

> One suspicious point about my eol code and its interaction with dirstate:
> for obtaining 'eol' versioned propertiy value I run for every entry
> method tree.id2path(fileid). I have suspicious that in the case
> of status --short inventory is not built, and every my lookup ends in
> building inventory in memory or something similar. Could be this is the
> case?

id2path is a surprisingly expensive operation, and if you're doing it
repeatedly, it's best to do something else instead.

Note that we are trying to avoid *ever* generating a full inventory, but
if we do generate one, we cache it.  I suppose it's possible that you're
doing something that invalidates the cache, but I think it's unlikely.

> Even if I rework my code to provide lazy lookup for 'eol' property this
> will not help for the case of many changes in the tree.

No, but scaling with the amount of change is the best we can hope to
accomplish anyhow.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH/5va0F+nu1YWqI0RApgzAKCE/Pj3gXmWXb7cyYGigeDVWA0TXQCfQ4PN
1o8vITsBzlqq2i8oPRf3Mco=
=PYJO
-----END PGP SIGNATURE-----