bzr log slower with packs

Bug #172975 reported by John A Meinel
4
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned

Bug Description

With Branch6 we no longer have the mainline revisions cached in a single file.
Which means that for 'bzr log' to determine the mainline of the branch, it has to iterate the history from the tip revision.

Packs make iterating history slower (at the moment) because they have more round trips to get the parents of each node, rather than buffering the revision graph.

The way we have defined our log display algorithm makes it difficult to show without loading the whole graph. "tsort.merge_sort" is defined to work on the whole graph. If our graph recorded children of nodes as well as recording ancestors of nodes, it might be easier to determine that it isn't possible for this node to have been merged before now.

Otherwise you have to keep searching backwards because an earlier node may have merged it. (Note, you *can* stop once you reach an ancestor of this node, since you can't merge a node into its own ancestor.)

There may also be a way to cache other information about the revision graph, which lets us answer the "give me all nodes merged into X which have not been merged into X-1" in a straightforward manner.

Until then, "bzr log" needs the whole graph.

Revision history for this message
John A Meinel (jameinel) wrote :

there is a workaround in the associated branch

Changed in bzr:
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
John A Meinel (jameinel) wrote :

log --long suffers from several apis that require the whole ancestry it uses get_revision_graph to do the merge_sorted call, and it needs to rebuild the revision history of the branch, so it knows what revisions are "mainline". (Some of that is because we used to have cached the mainline, so it was cheaper to ask for it, than to derive it while doing other things.)

Revision history for this message
John A Meinel (jameinel) wrote :

log --short isn't quite as penalized, but still suffers

Revision history for this message
John A Meinel (jameinel) wrote :

this bug is also related to bug #172567

Revision history for this message
Alexander Belchenko (bialix) wrote :

Number with bzr 1.0rc1 on my machine for log -r-1

bzr log -r-1 -v --long

knits 1.141
packs 7.235

bzr log -r-1 --long

knits 0.859
packs 6.750

Revision history for this message
John A Meinel (jameinel) wrote :

have you tried the patch I posted at all?

Revision history for this message
Alexander Belchenko (bialix) wrote : Re: [Bug 172975] Re: bzr log slower with packs

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

John A Meinel пишет:
> have you tried the patch I posted at all?

Mmm, probably not. Sorry if you think I made noise.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHVbyJzYr338mxwCURAt9ZAKCHkQSUIWUQH5CLPUrj44oJFdAjBwCfeeq4
VmYiDjppmsASYVHFZcQZJ8s=
=DOMH
-----END PGP SIGNATURE-----

Revision history for this message
John A Meinel (jameinel) wrote :

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

Alexander Belchenko wrote:
> John A Meinel пишет:
>> have you tried the patch I posted at all?
>
> Mmm, probably not. Sorry if you think I made noise.

Well, 1.0 is still slower, and we still need a proper patch for it. I was just
wondering if the associated branch helped for you. (It isn't a proper patch,
just a workaround.)

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

iD8DBQFHVcJBJdeBCYSNAAMRAslMAKCqVjOnrfTS2CkDHH9EnaUbaNLSHgCeIab6
5EtouzVXv79tR6/ksOTbXSo=
=6S9c
-----END PGP SIGNATURE-----

Revision history for this message
Alexander Belchenko (bialix) wrote :

John, your branch is not mirrored by LP. So I can't test your patch.

Martin Pool (mbp)
Changed in bzr:
status: Triaged → Confirmed
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
tags: removed: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.