I have had some experience using arrays as objects. My objects were floating length and I have used two techniques to deal with issues like yours (although not to do with destruction). My experience is that the solution is determined by the way you use the arrays. For instance in one solution my arrays needed to suport push/pop. Thus the "common" elements were stored in fixed addresses starting at 0. In another solution for reasons I dont exactly remember I used negative indexes to reach common data.

My guess is that you should probably do

$obj->[0]=Pixie::Object::Info->new()
[download]

After all the first element is always in the same location (versus the last) and this still allows push/pop which is slightly more efficient than shift/unshift.

But I still say that without knowing the operations you need to perform on your objects (why pick arrays?) there is no way to give a really good answer.

update
I think you probably should just use a different route. _Demand_ that any client class must support a given method, lets say $obj->for_pixie(). This method MUST provide the functionality that when called with a value it stores it. When called at all it returns its current value. Something like

sub for_pixie {
  my $self=shift;
  $self->[0]=shift if @_;
  return $self->[0];
}
[download]

This way if the storage you need is transparent to you, and if the client class doesnt happen to be implemented as an array then all they have to do is change the method. You could even provide a set of "standard" base classes that already have this functionality (and a new() as well) for different implementations. eg Pixie::Client::Array Pixie::Client::Hash Pixie::Client::Filehandle etc...

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.