Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^3: Array-based Inside-out Objects with Object::InsideOut

by rvosa (Curate)
on Feb 21, 2006 at 00:38 UTC ( #531562=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^3: Array-based Inside-out Objects with Object::InsideOut
Re^4: Array-based Inside-out Objects with Object::InsideOut
by jdhedden (Deacon) on Feb 21, 2006 at 18:30 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?
    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.
      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?
        Such corner cases would only be an issue with thousands of objects and hundreds of fields. In such a rare situation, you could always use hash-based fields for the infrequently instantiated class. Object::InsideOut handles any mixture of array-based and hash-based fields in different classes and in the same class.

        Remember: There's always one more bug.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://531562]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (9)
As of 2014-12-26 20:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls