[Rock-dev] 2GB + Autoproj + Ruby 1.9

[Peter Soetens]

On Tuesday 24 May 2011 12:22:43 Peter Soetens wrote:
> On Monday 23 May 2011 20:36:49 Sylvain Joyeux wrote:
> > On 05/23/2011 12:44 PM, Chris Mueller wrote:
> > > I'm not sure if 2 GB RAM are addressed to be insufficient, but i'm
> > > currently searching for improving
> > > my current situation.
> > 
> > The culprit are two files in the RTT package that take ~ 900M each to
> > compile. I asked on the orocos ML whether there was a way to "serialize"
> > the build of these two files in CMake in a portable way, but with no
> > results so far.
> 
> We found no portable way to express this is cmake. The only thing we can do
> is split these up in smaller files.
> 
> In addition, the merge of the rock master branch has caused a regression
> such that we need even more memory now to compile typekits. I can't
> quantify this, but we had a case where the BFL typekit could be compiled
> on laptop X against toolchain-2.3 but not against master, due to memory
> constraints.

on master:
$ time make RealTimeTypekitTypes.cpp.o
[ 68%] Building CXX object rtt/typekit/CMakeFiles/rtt-typekit-
gnulinux_plugin.dir/RealTimeTypekitTypes.cpp.o
                                                                                                                                                                                                                                                                               
real    0m56.000s
user    0m51.240s
sys     0m1.180s

on toolchain-2.3:
$ time make RealTimeTypekitTypes.cpp.o
Building CXX object rtt/typekit/CMakeFiles/rtt-typekit-
gnulinux_plugin.dir/RealTimeTypekitTypes.cpp.o
                                                                                                                                                                                                                                                                               
real    0m46.818s
user    0m45.590s
sys     0m0.980s

That's 20% increase in compilation time. I know that operations are the major 
blame for the total number. And I think we can compensate by simplifying the 
implementation (reducing features) of operations.

We might however also rethink how port connections are handled... a single 
port instantiates everything, itself, the connection (in 3 flavors), and the 
anti-port. I wonder for in-process communication, if we can't just byte-copy 
in a generic implementation of the channel elements.... still using the copy 
constructor of the object to hand-over the data from port to the channels.

Peter