Josh,
That's just what I was looking for - thanks. Performance is vastly
improved now, down to about 12% CPU usage on the same within-nodelet test.
Joel
Josh Faust wrote, On 17/09/10 10:30:
> Intraprocess publishing is only significantly faster if you're
> publishing a shared_ptr to the message, otherwise it still has to
> serialize/deserialize as usual.
>
> So instead of keeping an image as part of the class, filling that image,
> and then publishing it, you need to allocate the image each time you
> publish:
> sensor_msgs::ImagePtr image(new sensor_msgs::Image);
> sensor_msgs::fillImage(*image, "bgr8", height, width, 3 * width, data);
> pub_.publish(image);
>
> It doesn't look like this is explained anywhere on the wiki other than
> the cturtle release
> notes: http://www.ros.org/wiki/ROS/ChangeList/1.2/roscpp_changes#Publish.2BAC8-Subscribe_Changes,
> I'll remedy that tomorrow.
>
> Josh
>
> On Fri, Sep 17, 2010 at 1:01 AM, Cartwright, Joel J
> <J.J.Cartwright@hw.ac.uk <mailto:J.J.Cartwright@hw.ac.uk>> wrote:
>
> Hi all,
>
> I've been running some rough performance tests on transferring images
> using nodelets, and have found the overhead to be higher than I
> expected. For reference, I'm running ROS cturtle on Ubuntu 10.04 64 bit
> (stock kernel 2.6.32-24-generic) on a 2 GHz Intel Core 2 Duo laptop. CPU
> use monitored approximately using htop.
>
> Exchanging one 1920x1280 bgr8 image at 10 fps incurs ~30% CPU use for
> the nodelet manager. As expected, this is better than when the nodelets
> are run standalone (then ~25% CPU each), but I wanted to check if I'm
> doing something wrong that might affect nodelet performance. I've been
> using raw Image publishing rather than image_transport, to keep the test
> as simple as possible.
>
> The image 'source' is just an uninitialised unsigned char array of the
> correct size. As a comparison, I created a node that merely copies the
> source array a number of times, and found that 5 memcpy operations
> produce about the same CPU load as the best nodelet case, around 30%.
> Of course CPU caching may improve the speed of those 5 consecutive
> memcpy operations, so I'm not saying "ROS is copying the data 5 times".
>
> I've attached the relevant source files. The question is: Is this the
> best we can do at present for image transfer, and if not, are there
> modifications on the horizon that will improve performance?
>
> Joel
> --
> Research Assistant
> Ocean Systems Laboratory
> Heriot-Watt University, UK
>
>
> ------------------------------------------------------------------------
> Heriot-Watt University is a Scottish charity registered under
> charity number SC000278.
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org <mailto:ros-users@code.ros.org>
> https://code.ros.org/mailman/listinfo/ros-users
>
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
--
Research Assistant
Ocean Systems Laboratory
Heriot-Watt University, UK
(text/plain)