[ros-users] questions about nodelets and zero-copy messages

Jack O'Quin jack.oquin at gmail.com
Wed Nov 17 15:50:37 UTC 2010


My experimental nodelets are working pretty well now on cturtle,
thanks to help already provided.

These nodelets attempt to follow the "Intraprocess Publishing"
directions on the wiki:

  http://www.ros.org/wiki/roscpp/Overview/Publishers%20and%20Subscribers#Intraprocess_Publishing

So far, I have not been able to measure any performance improvements
over the old inter-node messages. It is always possible that I
misunderstood those simple directions and have somehow coded it wrong.

 * What is a good methodology for measuring the overhead of these messages?

I've been using "top" to observe the CPU overhead with various
combinations of subscribers, but it's hard to tell which nodelets in
the shared process are actually using up the time. Generally, I see
one process named "nodelet" with significant overhead and others using
a fraction of a percent. I am guessing this has something to do with
callback processing, but it's hard to learn much about what's going on
that way.

 * Is there some way to set different "command names" for the
different nodelets so top or ps can identify which is which?

 * How can I run "profile" on a nodelet or a collection of nodelets?

 * Are any enhancements planned for rxgraph to report nodelet
connections clearly?

If not, I'll open an enhancement ticket. The rostopic and rosnode
commands seem to report things correctly, so the right information
must be available somewhere.

I am guessing that memory allocation for large, high-bandwidth
messages could be a significant factor. Before, I pre-allocated the
messages to avoid memory overhead on every cycle. (But, I suppose that
just pushed the problem down into the publish() implementation.) Now,
I have to allocate a new message and shared_ptr every time.

 * Should I use the ros_realtime/allocators package in place of
standard C++ new? Are there examples of this I can study?

 * Are there other realtime allocation options I should look at?

It's really hard to figure out what to do without good profiling data
telling me where the bottlenecks are.

Regards,
-- 
 joq



More information about the ros-users mailing list