Inspired by previous discussions on using arrays with inside-out objects (inside-out objects using arrays?), I modified Object::InsideOut to allow the use of arrays (as well as hashes) for storing object field data.

I tested the performance of array-based Object::InsideOut objects on several platforms, and was impressed with the results: I got anywhere from 20% (Solaris) to 40% (ActivePerl) performance improvement for basic fetch and store operations over blessed-hash objects!

I hope this may prove to be sufficient incentive for some of my fellow monks to give Object::InsideOut a try. This lastest version is available on CPAN. Enjoy.

In addition to speed improvements, using arrays consumes less memory because Perl doesn't have to store hash keys for the object field data.

The programming effort for using hash-based inside-out objects and array-based inside-out objects is the same: You just use '@' instead of '%' when declaring your object data fields.

Update 2:
I just uploaded v1.01.00 which adds support for object serialization.

See New Module Announcement: Object::InsideOut for more discussion on Object::InsideOut.

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

Replies are listed 'Best First'.
Re: Array-based Inside-out Objects with Object::InsideOut
by ghenry (Vicar) on Nov 14, 2005 at 23:14 UTC

    Damn, I completely missed your module announcement and this answered my question, "Why wasn't this mentioned in Perl Best Practices"? Of course, it wasn't out then ;-)

    Can't wait to play with this tomorrow!


    Walking the road to enlightenment... I found a penguin and a camel on the way.....
    Fancy a Just ask!!!
Re: Array-based Inside-out Objects with Object::InsideOut
by rvosa (Curate) on Nov 18, 2005 at 00:41 UTC
    Hey, that's cool. I feel a bit flattered ;-)

    How do you generate and reclaim (or otherwise keep track of) the array indices?
      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.
        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.