Re: [Modeling-users] unloading CustomObjects

[Sebastien B. <sbi...@us...>]

Mario Ruggier <ma...@ru...> wrote:
[About EditingContext.refaultObject()]
> I can see this being very useful, My question is how do you
> keep track of which objects need to be freed? Do you do the
> bookkeeping separately? It might be nice to have EC's that
> automate this according to some criteria, such as, automatically
> drop (unfetch?) objects not accessed since 1 hour, or automatically
> unfetch all the least recently accessed objects beyond N, where N is
> some positive number (i.e. keep only the most recently accessed N
> objects).

This is the second step, right, the automation of the process will be
made separately. This API only allows you to make it by hand.

  However, rethinking of this, I'm wondering if the way it is done will
  actually free as much memory as expected... Here are details on the
  process exposed in the patch:

    - deincrement the snapshot reference count for an object in the
      database's cache. If the refaulted object is the last one
      referencing the snapshot, the snapshot is freed.

    - revert the object into a fault. Doing this basically means: call
      __init__() to reset its value to their defaults, and mark it as a
      fault by storing an instance of AccessFaultHandler in it. This
      step does not free a lot of memory, although your objects'
      attributes have a big memory footprint: basically, you still have
      the reinitialized object in the EC.

  So the most significant impact on memory (unless, I repeat, your
  objects are quite big and some of their attributes contains instances,
  such as FixedPoint instances) will occur when forgetting the
  snapshots.=20

Hmmm... This needs to be checked in details. I'll probably also compare
with ZODB ghosting mechanisms and its impact on memory. Probably other
approaches might be taken, such as:

  - having a shared EditingContext holding mostly read-only objects that
    are used by an application: this would make it possible to
    manipulate these objects in <n> different ECs while having only one
    (instead of <n>) instance for each on them,

  - changing the object's class into FaultHandler, instead of
    reinitializing its values and storing a FaultHandler instance in
    it.

To be continued...

-- S=E9bastien.