[ros-users] ROS cpu load

[Ken Conley]

Thanks for the great analysis. I've updated pmon.py (r10575), as I agree
that that loop can run slower.  What was the CPU usage before that?

You previously mentioned getting some numbers on rospy -- I'd love to know
if you see any issues there or not, even if you don't have time to track
down more fast loops. AFAIK, the main problem with rospy is that Python
gobbles up memory when you use threads, and rospy is a bit too greedy in
this regard. The hope is to redo the threading model in a future rewrite,
but it's good to understand the current issues when prioritizing.

thanks
Ken

On Sat, Jul 31, 2010 at 11:28 AM, Cedric Pradalier <
cedric.pradalier at mavt.ethz.ch> wrote:

>  On 07/31/10 13:11, Cedric Pradalier wrote:
>
>
> To continue on my fight against overhead, I've had good performance
> improvement of rosout by replacing all the timeout argument in the
> CallbackQueue::callAvailable and CallbackQueue::callOne from 0.01s to 0.1s.
> Now my rosout is really sitting in a corner doing nothing while I'm not
> logging.
>
> Can you foresee any drawbacks from this change?
>
>
> And the final touch to make roscore behave: in package roslaunch, file
> src/roslaunch/pmon.py:570
> replacing time.sleep(0.01) with time.sleep(0.1) makes roscore use less than
> 1% cpu, and AFAICS just slows down a little the process respawn mechanism.
>
> I don't think I will optimise farther for now. In summary, applying all the
> changes in this thread brings my set of core processes (roscore, rosmaster,
> rosout, some serial data gatherer/publisher) from a total of 20% cpu load,
> to 5-6%, without any noticeable performance loss so far.
>
> HTH
>
>
> --
> Dr. Cedric Pradalierhttp://www.asl.ethz.ch/people/cedricp
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100731/3561bee7/attachment-0003.html>