<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>