[Insight-developers] note on data accessors

[Miller, James V (CRD)]

(Brad can correct me on the standard, but here is my interpretation of "inline".)

"inline" is only a suggestion to the compiler.  The compiler can choose not inline methods marked
inline.  So even if a method is marked inline and the code appears in the .h file, it is not
guarenteed to be inlined.

The only way I know of to force a routine to be inlined is to put the implementation in with the
declaration of the function, i.e. within the class body.  This makes for ugly header files but if the
inlined methods are short (which they should be) then it usually is not too bad.



-----Original Message-----
From: Luis Ibanez [mailto:ibanez@cs.unc.edu]
Sent: Saturday, February 03, 2001 9:39 PM
To: Joshua Cates
Cc: Insight-Developers
Subject: Re: [Insight-developers] note on data accessors


Josh Cates wrote:
> A note on itkDataAccessor:
> I have been playing around with the itkDataAccessor object in some of my
> code and found that gcc -O2 doesn't seem to optimize away the inline
> Get/Set functions.  It would appear you have to go to -O3.
> 
> Josh.

Thanks for pointing this out.
This is quite important because *every* 
pixel access uses one of those calls.


Here is a test to verify whether the calls to Get()/Set()
methods of DataAccessor are being inlined or not.

Unfortunately the only way to know that for sure is
to check the assembly code generated by the compiler.

This can be done, for example by:

1- Compiling on gcc with the option -S.
   that will generate a *.s file, instead of a *.o.
   the .s file contains the code in assembler corresponding
   to the .cpp source file.

2- Using ddd (the data display debugger) and selecting in
   the menu option 'source' display machine code.

3- On VC++ it can be done by a selection on the debugging 
   windows menu

------

The test was done with the following lines of code:

  ImageType::Pointer image = ImageType::New();
  ImageIteratorWithIndex< ImageType > 
  it( image, image->GetRequestedRegion() );
  it.Set( 17 );    // here itkDataAccessor::Set() is called
  it.Set( 33 );    // here itkDataAccessor::Set() is called


When the code is compiled on with gcc -S
the last three lines are translated into:

   ...
   call   _ImageIteratorWithIndex(...constructor...)
   ...
   movl   -24(%ebp),%eax
   movl   $17,%eax
   movl   -24(%ebp),%eax
   movl   $33,%eax
 

%eax represents one of the four main registers on 80x86
architecture. %ebp is the frame pointer that allows to
point to a particular position in memory. 
So, Set() seems to be inlined as expected.

And this is the same whether we use:

   -g -O2 -S

or

   -g -O3 -S



However, there are several other calls that were 
supposed to be inlined an that are not.

For example the constructors and operator= on
itkRGB are not being inlined.  It was necessary
to add the 'inline' keyword on the header and
to compile without debugging in order to get them
inlined.

It seems that we are relying too much on templates
assuming that they will inline most of their methods,
and we have not used 'inline' enough.

A grep on Code/Common shows that the keyword
"inline" is used in only 16 out of 180 header 
files.

BTW the use of 'const' can also help the compiler
to optimize expression, because in some cases it
can avoid to put them in memory variables.





Luis




_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers