Revision history [back]

I'm having the same issue, with the latest publicly available version of rosbridge accessing using TCP Sockets.

Messing with the code and with some profilers, I've seen that there's a loop in the serveForever function in ws.py file that is what's consuming most of the cpu time.

What I've seen is that in the loop there are two calls to the select method. These calls have a timeout which is configurable using the --hz parameter. But in my case this parameter changed nothing.

The thing is, that these selects were returning immediately, because my socket was available for output (the outputReady list contained a connection to my socket). Therefore the loop spinned forever without control or sleeps.

My solution (though it might have many side effects, i've not tested it extensively) is to replaced the outgoing parameter in the first select, and the incoming parameter in the second select, with an empty list.

What this does is that the first select doesn't end immediately, and waits for its timeout, which reduces the CPU usage to 8% on my computer. Still a lot, but I guess you can play with the hz parameter to reduce it even more.

I'm having the same issue, with the latest publicly available version of rosbridge accessing using TCP Sockets.

Messing with the code and with some profilers, I've seen that there's a loop in the serveForever function in ws.py file that is what's consuming most of the cpu time.

What I've seen is that in the loop there are two calls to the select method. These calls have a timeout which is configurable using the --hz parameter. But in my case this parameter changed nothing.

The thing is, that these selects were returning immediately, because my socket was available for output (the outputReady list contained a connection to my socket). Therefore the loop spinned forever without control or sleeps.

My solution (though it might have many side effects, i've not tested it extensively) is to replaced the outgoing parameter in the first select, and the incoming parameter in the second select, with an empty list.

What this does is that the first select doesn't end immediately, and waits for its timeout, which reduces the CPU usage to 8% 3% on my computer. Still a lot, but I guess you can play with the hz parameter to reduce it even more.