[Insight-developers] Empty FixedArray destructor: Performance hit using gcc (times 2)

[Brad King]

Bill Lorensen wrote:
> OK, I am way out of my league here, but the difference may be the way
> POD ("Plain old Data") types and non-POD types handle memory
> allocation.
> 
> See: http://www.fnal.gov/docs/working-groups/fpcltf/Pkg/ISOcxx/doc/POD.html
> 
> It may be, that by having a destructor, the class becomes a non-POD
> class. Without it, it may be a POD class. The POD-ness rules are
> complex, at least for me.
> 
> Perhaps Brad King can shed some light on this. These questions are NOT
> out of his league.

Sorry for the delayed response but I've been away from email all
afternoon.  Here is what is going on, using Luis's test case from
elsewhere in this thread:

class MyArray
{
public:
  MyArray() {};
  ~MyArray() {};
  double operator[](unsigned int k) { return foo[k]; }
  double foo[2];
};

Since double does not *have* to be aligned at 8 bytes on x86 the
alignment of this struct is 4 bytes...WITH OR WITHOUT the destructor.
Now consider the code

  void* x = new MyArray[2];

It's the address to which 'x' points that changes when the destructor is
added or removed.  The malloc that is done returns an 8-byte aligned
memory buffer in both cases.  It's operator new that adjusts it.

When the destructor is present GCC needs a place to record the length of
the array so that upon deletion it knows how many times the destructor
needs to be called.  Their implementation allocates 4 additional bytes
of memory and chooses the first 4 bytes of the resulting buffer to store
this count so the data are placed starting at 4 bytes past what was
returned by malloc, and that value is stored in x.  Then all the doubles
get poorly aligned and performance suffers.

When the destructor is not present it does not need to do anything at
deletion time but free the memory, so no count is needed and the buffer
returned by malloc is used directly.  The doubles end up with good
alignment.

-Brad