[RFC] question about different behavior of WorkingTree.iter_changes

[John Arbash Meinel]

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

Aaron Bentley wrote:
| Alexander Belchenko wrote:
|
|> Can you shed some light why you said:
|
|> "id2path is a surprisingly expensive operation, and if you're doing it
|> repeatedly, it's best to do something else instead."
|
| I think my advice is a bit out-of-date.  I remember that it used to be
| expensive to hit id2path for every path in the tree for inventory-based
| trees, like RevisionTrees.  For dirstate-based trees, I guess
| tree.id2path very efficient.  Sorry for any time of yours that I've wasted.
|
| Aaron

Dirstate has a fast path2id and a slow id2path. I think for Revision trees both
are a little bit slow, though id2path is probably slower of the two.

For Dirstate, id2path has to generate a whole-tree file-id => path cache, which
should be reused, but is still a whole-tree operation the first time. The
in-memory objects are stored keyed on (dirname, basename, file_id) which means
you would have to iterate through the whole list each time for id2path. However,
I thought we built a cache that got re-used, so the only chance I can think of
is if there is a bug in that code/you are invalidating it.

The details are actually hidden by the _get_entry(file_id=file_id) call. That is
where the expensive work happens if you didn't pass a "path_utf8=" parameter.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIArE/JdeBCYSNAAMRAs+UAKCrMQP6mv1bDHF07w6VQP4h63SZngCgwGnd
Hf6lkTiSApuiIwqd1xRFsqE=
=88nE
-----END PGP SIGNATURE-----