http://qs1969.pair.com?node_id=509658


in reply to Re: Array-based Inside-out Objects with Object::InsideOut
in thread Array-based Inside-out Objects with Object::InsideOut

Array indices (object IDs) are generate by sequences (starting with 1). There is one sequence for each class tree.

When an object is destroyed, it's ID is reclaimed as part of the DESTROY subroutine. Reclaimed ID are maintained in a queue, one per class tree. Reclaimed IDs are doled out first, of course.

Remember: There's always one more bug.
  • Comment on Re^2: Array-based Inside-out Objects with Object::InsideOut

Replies are listed 'Best First'.
Re^3: Array-based Inside-out Objects with Object::InsideOut
by rvosa (Curate) on Feb 21, 2006 at 00:38 UTC
    Do you notice any performance degradation when instantiating and destroying lots and lots of objects across a large-ish (well, more than one class) inheritance tree? I wonder what the effect is, both memory-wise and on lookup speed, of having large and sparse class arrays that hold the object data.
[reply]
      Do you notice any performance degradation when instantiating and destroying lots and lots of objects across a large-ish (well, more than one class) inheritance tree?
      If you're instantiating AND destroying objects, then there should be no performance degradations as object IDs are recycled. The size of the field arrays does not grow larger than the largest object ID. The largest object ID is determined by the maximum sum of all objects in an inheritance tree that exist at any moment. For example, even if you create and destroy a million objects, but only every have one thousand in existance at any one time, then the field arrays will never exceed 1000. Further, array lookup time is not affected by array size: It is always a constant.
      Remember: There's always one more bug.
[reply]
        Further, array lookup time is not affected by array size: It is always a constant.
        That reassurance was probably part of what I was looking for. I get what you're saying about the reclaiming of IDs, but I can imagine a corner case: say that some object in the inheritance tree only gets instantiated once in a while, and others in the tree are instantiated far more often, but they share the ID generator and ID pool.

        Then, any array holding instance data in the class that is only instantiated ever so often will be a fairly sparse array. I wonder if that's more memory-efficient than a hash. I don't know enough about the perl guts to be able to say whether memory is also allocated for the unused array elements in that class. Anyone?
[reply]

In Section Meditations