<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
A while back, I did some basic profiling of the image pipeline and it<br>
looked like a large percentage of time was being spent de/serializing<br>
the data. For some reason packaging up 640x480x15fps uncompressed color<br>
images into messages and sending them over a wifi connection doesn't<br>
work that well when you are running on an Atom Processor.<br>
<br>
Improvements here might be useful, though the effort is probably better<br>
spent converting the image pipeline to use nodelets or waiting for<br>
another rev of Moore's Law.<br>
<br></blockquote><div><br></div><div>Images are unfortunately just about the best case for serialization -- they end up as mostly just a single big memcpy.  There is a deserialization improvement that may be possible though, which I just codified in a ticket: <a href="https://code.ros.org/trac/ros/ticket/3000">https://code.ros.org/trac/ros/ticket/3000</a></div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On several occasions we have worried that ROS would be slow but our<br>
experience has shown that the best approach is to skip worrying about<br>
the performance of ROS and just get the code working. Once the code is<br>
working it is a lot easier to optimize and we have almost always found<br>
that the slowest part is our code or the WiFi connection.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>This is good to hear, thanks.  That has been our experience as well in most cases -- and nodelets seem to satisfy the others so far.</div><div>

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