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@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 Pradalier
http://www.asl.ethz.ch/people/cedricp

_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users