Branch.lock_read() rather expensive

[Aaron Bentley]

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

John Arbash Meinel wrote:
> What I found was that quite a bit of time was taken up, just in
> lock_read(). I figured part of this is because nothing takes out a read
> lock beforehand, so it takes out 1 read lock for each revision it parses.
> To prove this, I wrapped the common_ancestor() call with a lock/unlock
> statement, and this is what I found

Ah.  I didn't understand the mechanics here.  I assumed if I didn't
explicitly lock it, it wouldn't be locked at all.

> I'm guessing that the common_ancestor,revision_graph, and
> get_intervening_revisions() are too expensive as it is, but I thought I
> would point out a fairly major performance issue.

revision_graph can be reimplemented in terms of the inventory weave, the
way is_ancestor is.  I don't understand the weave API well enough to do
this.

node_distances could be memoized (well if we assume there are no ghost
revisions.  We can invalidate the cache when a ghost has been fixed.)

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

iD8DBQFDUXK10F+nu1YWqI0RAs3YAJ92eXaM3Ow+v36MIQ8TfjOoABNd5ACdGdZZ
shJHgWuqW9F0TlDgC9YhmXc=
=vokD
-----END PGP SIGNATURE-----