There are two reasons we are experiencing slowdowns and increased binary code
size during compiling:
* The regeneration of template code in every compilation unit (.o file)
* The use of boost::fusion template magic used in Operations which today's
compilers can barely handle.

The first item we can solve on the short term, the second only on the long
term.

For reducing the regeneration problem, typegen/orogen creates a Types.hpp file
which defines all 'extern template' class definitions which are available in the
typekits. When you include this header file, you also need to link to the
typekit library, but your component size might be cut in half (I tested this
with our HelloWorld component for example). I have a patch that when you
include a new file, <rtt/typekit/Types.hp

, you get this behavior for all
RTT primitive times (int, double,...). Since we don't know if you included
this header, we need to link at all times with the rtt typekit in our
UseOrocos.cmake macros.

A next step would be to include this Types.hpp header in <rtt/RTT.hp

such
that it is always included by most user code. Unfortunately, people not using
the UseOrocos.cmake macros will get hit by a bunch of undefined symbols, until
they link with the rtt typekit.

In the long run, I see no other option than to have components link with the
typekits of the types they use. I wouldn't introduce this in 2.2, but I would
consider it for 2.3. Please provide feedback for your use case.

On the boost::fusion front, I have reported earlier about the non-linear
increase in compilation times (with gcc) when using this library. We've had
some off-list discussions. We're not going to make major changes or any change
in the API of Operations. We'll probably 'optimize' for 1-in/1-out operations,
that is, a pure request/reply operation which would then be very cheap
compilation time wise. So these signatures:

   void foo( void );
   void foo( T in );
   R     foo( void );
   R     foo( T in );

Which would allow us to drop boost::fusion for that case and have 1.x-like
compilation times again. If you add more arguments to 'foo', you're back at
square #1, ie the way it is today.

We've also been looking at making lua-invoked operations hard real-time.
The conclusion here was that operations, as they are implemented now, impose a
considerable complexity on the RTT and that it wouldn't be easy to tinker with
that design to make that happen. That, and the fact that we want to invest in
tools and not so much more in low levels, makes that there is no direct
roadmap ready for that.

With the rest, we're very happy though :-)

Peter