[Zope-dev] ZOBD and pointers

[Tim Peters]

[Yair Benita]
> ...
> Reading this answer I understand that anything I store should be
> persistent, even if its a list I don't plan to edit.

I wouldn't say that.  For example, for _most_ applications it would be
foolish to create a subclass of Persistent to store an integer, as
opposed to just storing an integer directly.  I can conceive of
(unlikely!) applications where there may be advantages to storing
integers as perisistent objects, though.  In the same vein, if there
aren't multiple references to a single small list that doesn't change,
there seems little (if any) point to making that a PersistentList.

Note that there are other tradeoffs here too.  For example, an
attribute whose value is persistent is not loaded into RAM when its
parent is loaded into RAM, but the full state of non-persistent
attributes is loaded into RAM at the time their parent is loaded into
RAM.  That can have a major effect on time and memory demands, and in
opposing directions.  Or it may not -- it depends on details of the
application's object access patterns.

> I was under the impression that a subclass of persistent will be larger in size
> for storage, so I avoided it in the cases mentioned. Is this true?

Create a specific class definition, and it's easy to measure.  It
depends on the class.  Certainly it costs more space to create a
persistent version of a builtin Python type, and for the same reason
it costs more space too to create any user-defined subclass of a
builtin Python type.  But for an object of a user-defined class, a
persistent version takes more RAM when it's in memory (because it has
to store info like the oid, and _p_changed, that non-persistent
objects don't have), but the on-disk size is at worst roughly the same
(e.g., the values of persistent attributes like _p_changed and
_p_state don't get stored to disk, they only exist while the
persistent object is in RAM).

If I were you, I'd spend some quality time with fsdump, and figure out
where the bulk of your space is going.  Details matter more than
"general principles" here.  If you use the fsdump.py from ZODB 3.4
(which can be used with .fs files created by ZODB 3.1 and 3.2 too), it
displays the byte size of data records, which can be a real help in
such analysis.