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