On 07/31/10 01:56, Josh Faust wrote:
> There are a couple different polling timeouts used that may affect this:
>  xmlrpc_manager.cpp:256:   server_.work(0.01);
>  poll_manager.cpp:95:  poll_set_.update(10);
>
> If you're using timers:
>  timer_manager.h:508:  timers_cond_.timed_wait(lock,
> boost::posix_time::milliseconds(1));
>
> Adjusting these to your needs will likely help quite a bit -- we don't
> run on any embedded systems here, so we're haven't optimized for them
> or provided knobs to tweak for these.

Thanks a lot.
Changing the 2 first timeouts to 0.1 and 100 respectively my process
much much lighter on my system. My real program is now oscillating
around the 1% mark, which match my expectation for something gathering
data on a serial port and publishing them at 30 fps.

I'm not quite sure what is the drawback of this change. My understanding
is that it will make the program termination and some connection closing
a little bit slower. Is there something more?

Now, I'm not using timers in these programs, so I cannot say what is the
influence of the 1ms wait in timer_manager.h. I have not looked at the
code in details, but it look like this wait could be advantageously
replaced by the following code:

      int remaining_time = std::max((int)((sleep_end.toSec() -
current.toSec())*1000),0);

      timers_cond_.timed_wait(lock,

boost::posix_time::milliseconds(std::min(50,remaining_time)));

Is there any reason to verify that the time is not going backward at 1kHz?