[MERGE] Make _nodes_by_key lazy

John Arbash Meinel john at arbash-meinel.com
Wed Aug 27 02:58:08 BST 2008

Hash: SHA1

Robert Collins wrote:
> Robert Collins has voted resubmit.
> Status is now: Resubmit
> Comment:
> Rather than copying in the duplicate code, please refactor the base to
> have a helper method that does the stuff we want to reuse.
> For details, see:
> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48B304BB.9020409%40arbash-meinel.com%3E
> Project: Bazaar

The problem is that the signatures aren't the same on the 3 different objects
I worked on. Nor are they all inherited among eachother.

GraphIndexBuilder, GraphIndex, and BTreeBuilder each do something a bit different.

GraphIndexBuilder._nodes := {key: (absent, value, refs)}
BTreeBuilder._nodes := {key: (value, refs)}
GraphIndex:_nodes := {key: value} OR {key: (value, refs)}
Also, GraphIndex.node_has_refs versus GraphIndexBuilder.reference_lists.

It doesn't seem like you can do _nodes => _nodes_by_key in a common way
between all 3 functions.

I *can* pull the specific code out of add_node, but if you look closely the
Btree code isn't the same as the GraphIndex code. Mostly, because it doesn't
need to add an entry for absent nodes. Which is important for my other
optimizations. (You don't have to check if the present node is actually
absent, you don't have to check if it is actually absent in _iter_mem_nodes, etc.)

I'm not sure what you think I can factor out. If you could point it out to me,
I would be happy to do so.

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


More information about the bazaar mailing list