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

[Brad King]

Niels Dekker wrote:
> Brad's explanation is a major eye opener to me as well.  :-)  I never
> realized before that there could be such a relation between the byte
> alignment of the object allocated by new T[N], and the destructor
> T::~T().  Thanks Brad!
> 
> Basically the relevant new-operation is at
> "itkImportImageContainer.txx", right?
> ImportImageContainer::AllocateElements does:
>  data = new TElement[size];
> 
> So removing the user-defined destructor from FixedArray would /only/
> solve the issue when TElement (the pixel type) is a FixedArray. And even
> in that case, I guess it /only/ solves the issue when the element type
> of FixedArray doesn't have a user-defined destructor. Right?
> 
> I think the issue /could/ be solved more generally, by avoiding new [],
> and using malloc instead.  Within ImportImageContainer::AllocateElements:
> 
>  data = static_cast<TElement *>(
>    std::malloc( sizeof(TElement)* size) );
> 
> I'm not a fan of using malloc in general, but this /might/ be a valid
> reason to do so...  Unfortunately std::malloc does not construct the
> data elements, so it should be followed by a placement new, to do the
> construction in-place:
> 
>  new ( data ) TElement [size];
> 
> If we would do so, each delete [] call in itkImportImageContainer.txx
> should be replaced by explicitly destructing the elements of
> m_ImportPointer, followed by std::free(m_ImportPointer)...
> 
> What do you think?

This could work, but it seems like a lot of effort to support one
compiler on one platform.  The compiler is obeying alignment rules in
the behavior I described, but we just haven't told it that double should
be 8-byte aligned.  Passing -malign-double solves the problem.

-Brad