bb very slow?

John Arbash Meinel john at arbash-meinel.com
Thu Jul 17 16:35:04 BST 2008


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

Aaron Bentley wrote:
| Robert Collins wrote:
|> On Thu, 2008-07-17 at 07:10 -0400, Aaron Bentley wrote:
|>> -----BEGIN PGP SIGNED MESSAGE-----
|>> Hash: SHA1
|>>
|>> Robert Collins wrote:
|>>> I'm finding BB page clicks are taking 20-30 seconds to fulfil...
|>> I'm not finding this.  Are you still?
|> 8 seconds to show the merge requests page for me, just now.
|
|> So its better, but ...
|
| 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.
|
| Aaron

How are PQM's revision ids different than others? 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)

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


That should let you scale by O(changes) rather than O(all_history).

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

This should also be safe if a few patches get merged before BB notices.

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

iEYEARECAAYFAkh/ZqgACgkQJdeBCYSNAAMPIQCfdscRe0FRbbAS+HA/+zSgXvDV
xtQAoKG16qxGBaqLsB5fnDXvsGTo+qyP
=PknZ
-----END PGP SIGNATURE-----



More information about the bazaar mailing list