[MERGE] Add an InventoryEntry cache for xml deserialization

[Martin Pool]

On 11 Dec 2008, John Arbash Meinel <john at arbash-meinel.com> wrote:
> > I'd introduce immutable versions of the objects; CHKInventory wants this
> > too.
> 
> So my idea was to have a flag for the code to indicate that it promises
> not to mutate them. Converting the first 1k revisions of MySQL drops
> from about 2.5m-3m to 2m with non-copied file records.
> 
> I agree immutable would be nice, but I don't see how to do that without
> 
> 1) Going down to C/Pyrex where you can easily declare an attribute readonly
> 2) Replacing the attributes with properties, but I imagine that will add
> a certain amount of overhead. I'm not sure how much versus (1).
> 
> Anyway, in the short term we can get most of the benefit, and have an
> obvious place to toggle if we want to get the rest.

I'm working as a while-travelling-project on a namedtuple or similar
object in C.  I was originally thinking of using it in dirstate.py,
which currently uses tuples, to make it more readable than multiple
nested numeric indexes.  

This may also help InventoryEntry objects a lot by making them cheaper
to construct.  It would also be a chance to make them easily immutable
after creation.  However, it may not be feasible if it's too disruptive of
an api change, either in making them not real objects, or not mutable,
etc.

It's not done yet but it is at <https://launchpad.net/python-miniobject>
and <https://code.launchpad.net/~mbp/bzr/with-miniobject>

> 
> And again, I don't want to spend a huge amount of effort on the existing
> inventory code, because no matter what we do, it is still an O(tree)
> operation. But it would be nice to be able to convert mysql in say an
> hour, instead of it taking overnight.

Me too.

-- 
Martin