>
>> Shared memory transport is a common feature request. There's a long
>> discussion of the issues at
>> http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html<
>> http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html%20>that
>> should get you caught up.
>>
>>  This links says me "Not found"...
>

The first link works:
http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html


>
>  Short version:
>>  * We haven't found shared memory transport of serialized data to be a
>> significant improvement versus TCP over loopback, but are interested in
>> evidence to the contrary.
>>  * Storing the message objects themselves in shared memory could be a win,
>> but gets very complicated to implement.
>>  * We've focused on optimizing intra-process (no-copy) message passing and
>> are developing the nodelet <http://www.ros.org/wiki/nodelet>
>> infrastructure; big point clouds are the motivating use case.
>>
>>  Similarly, I don't observe a significant performance gain on my laptop
> either. From htop output, I could make myself believe that 5-10% perf gain
> are possible, but this is clearly marginal. However, it might be different
> with more active processes, more cpus, less cpus, more/less rams, bigger use
> of the network stack, different hardware (gumstix?), so I would tend to put
> this image_transport_plugins in the common pool, just in case.
>

Again, without data showing it's faster (and perhaps a testsuite so that
others can test on different configurations), it's not worthwhile.  Nodelets
will be orders of magnitude faster for any but the smallest images (where
they will still be faster).

You're welcome to put this in your own repo and share it with the
community.  I would suggest fixing some of the boundary cases first though.

Josh