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

[Luis Ibanez]

Tom,


The FixedArray destructor was removed yesterday:

http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkFixedArray.h?root=Insight&r1=1.40&r2=1.41
http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkFixedArray.txx.diff?cvsroot=Insight&r1=1.22&r2=1.23

So far, the secondary effects seems to appear in
the builds that have Explicit Intantiation turned ON:

http://www.cdash.org/CDash/viewBuildError.php?buildid=94739
http://www.cdash.org/CDash/viewBuildError.php?buildid=94689
http://www.cdash.org/CDash/viewBuildError.php?buildid=94872

Where the destructor is not found at link time...

It also seemed to affect the test for
itkFastMarchingExtensionImageFilterTest:
http://www.cdash.org/CDash/testSummary.php?project=2&name=itkFastMarchingExtensionImageFilterTest&date=20080608



    Luis



----------------
Brad King wrote:
> 
> 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
>