On 10/13/06, Patrick K. O'Brien  wrote:
> Mike Orr wrote:
> > On 10/12/06, David Binger  wrote:
> >> This seems llike a Python issue more than a Durus one.
> >
> > That occurred to me after I sent the message.  I've been looking over
> > the Durus source, and the only amount of data it seems to add are four
> > little attributes in PersistentBase.
>
> If you'll recall a discussion from a while back, I made use of slots
> throughout the Schevo fork of Durus, which saved a lot of memory at the
> expense of arbitrary attributes.

Excellent idea! I put .__slots__ in the main chemical object and the
memory use cameo down to 121 MB (from 150).  Since this class is
non-persistent and I only have five or six persistent classes in the
database (all BTree or PersistentDict's), I don't think it'll help
much to use a modified Durus but I'll give it a try. Maybe it will
help all those BNode objects?  I'm installing Schevo now.  It's
drop-in compatible with Durus?

>  I seem to recall that you didn't want
> to give up your arbitrary attributes, particularly on the root object.

I withdraw that objection. I switched back to using keys on the root
object.  I was trying to make the database more transparent to the
rest of the application, but now I have a domain class that handles
all database access.

There's no technical reason the root object has to be a
PersistentDict, is there? It could be any Persistent object? What
about an argument to the Storage constructor thus:
    root_factory=PersistentDict
Then ppl can make databases whose root object is their own custom container.

--
Mike Orr