[MERGE] Improvements to find_unique_ancestors()
Ian Clatworthy
ian.clatworthy at internode.on.net
Tue May 20 14:31:27 BST 2008
John Arbash Meinel wrote:
> For a performance comparison...
>
> If I run a graph search on the last 100 merge nodes in bzr.dev, it takes an
> average of 320ms to find the unique nodes. With this code, it takes an
> average
> of 115ms. So it is approx 2x as fast.
Really well done on these improvements! I'm rather keen to see this
land so I've spent much of this afternoon/evening reviewing it. I can't
see anything wrong code wise but I'm not comfortable approving it yet.
I think it needs 2 changes made:
1. find_unique_ancestors() is simply too long - it covers 4+ pages
when printed - making it unmaintainable by people like me with
smaller brains. I'm aware of the performance emphasis here but
still feel it could be broken up into a master method that calls
two or three helper methods. Those helper methods can contain the
loops, rather than being called inside the loops, so performance
shouldn't be impacted by a noticeable amount.
2. The algorithm outlined in the opening large comment needs updating
to cover the information contained in your email.
As a minor note, several of the _mutter calls probably ought to be
using %d instead of %s. It's pretty minor compared to the issues above
though.
bb:resubmit.
I realise that this patch doesn't necessarily make things that much
less readable than the existing code. FWIW, I was happy to approve the
earlier patch because I knew you had a follow-on one coming.
Let's hope we don't need to come back to this method again for a while
now - let's leave it both faster and easier to read please.
Ian C.
More information about the bazaar
mailing list