<div class="gmail_quote"><div>In general, nodelets don't guarantee that your CPU usage will go down.  While it is often the case, if the message passing itself is already a small part of your usage, nodelets won't help that much.  They will help latency of the passing though.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 * What is a good methodology for measuring the overhead of these messages?<br>
<br>
 * Is there some way to set different "command names" for the<br>
different nodelets so top or ps can identify which is which?<br>
<br>
 * How can I run "profile" on a nodelet or a collection of nodelets?<br></blockquote><div><br></div><div>You profile nodelets the same way you profile any C++ application: with the profiler of your choice.  I tend to use google perftools and/or cachegrind.  There's also gprof and sysprof, and probably many more.</div>


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 * Are any enhancements planned for rxgraph to report nodelet<br>
connections clearly?<br>
<br>
If not, I'll open an enhancement ticket. The rostopic and rosnode<br>
commands seem to report things correctly, so the right information<br>
must be available somewhere.<br></blockquote><div><br></div><div>That information doesn't exist anywhere at the moment.  As far as the ROS graph is concerned, it's just a single node.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<br>
I am guessing that memory allocation for large, high-bandwidth<br>
messages could be a significant factor. Before, I pre-allocated the<br>
messages to avoid memory overhead on every cycle. (But, I suppose that<br>
just pushed the problem down into the publish() implementation.) Now,<br>
I have to allocate a new message and shared_ptr every time.<br></blockquote><div><br></div><div>Don't guess, profile.  Allocation could be a bottleneck, but it's more likely that filling in the data (or std::vector's 0-filling of primitive types on resize) is the problem.</div>


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 * Should I use the ros_realtime/allocators package in place of<br>
standard C++ new? Are there examples of this I can study?<br></blockquote><div><br></div><div>The allocators package currently only has an aligned allocator, so that won't help.  What might help is a growable (and shrinkable) version of lockfree's ObjectPool.  You could probably try using those if you're OK having a fixed-size pool of messages.</div>


<div><br></div><div>Josh</div></div>