bb very slow?

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> | In order to accomodate PQM's revision-ids, I've had to switch to a
> | slow-but-safe way of determining whether a merge occurred.  So whenever
> | there's a new HEAD in bzr (or a monitored project with a similar-size
> | ancestry), we may see this kind of behavior.
> 
> How are PQM's revision ids different than others?

They have percent signs in them.

> Could you do something
> like:
> 
> # cache the ancestry of the current tip
> 
> # when tip changes use
> g = b.repository.get_graph()
> new = g.find_unique_ancestors(new_tip, [old_tip])
> ancestry.add(new)

Interesting.  I'm not used to thinking about the long-livedness of this
process.

> for patch in unmerged_patches:
> ~  if patch.revision_id in ancestry:
> ~    # This has been merged

So I'm currently constructing an SQL query for all requests that are
unmerged but whose head revision is in the ancestry.  That also has
performance advantages, since only a requests will survive that filtering.

Your approach will probably deliver reasonable performance, but it's
frustrating to have to change approaches just because SQLAlchemy can't
efficiently encode a test for whether a value is a member of a set.

> Alternatively the final check could be done on just "new" and you
> wouldn't need to cache the whole ancestry.

Call me paranoid, but I think it's safer to check against the whole
ancestry.

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

iD8DBQFIf2150F+nu1YWqI0RAuBfAJ9QeLCIh4cbgxl8Ek7W7+mgIEbNNgCfafkD
Hs8QOok1GEUJ39jyzKYPYUI=
=ewg4
-----END PGP SIGNATURE-----