Add start-parameter-event-subcriber option
In the efforts of reducing CPU usage for embedded platforms, this PR is created to give the option to start or not the parameter event subscriber.
Benchmarks on RPi1 (single core running at 700Mhz) shows that CPU is reduced about 2% when this parameter event subscriber is not created.
Given that currently we have the option to NOT start the parameter event publisher, makes sense to have also the option to not start the parameter event subscriber.
@alsora @dgoel
Hello! Any updates on this?
@wjwwood @hidmic for more feedback.
@mauropasse I think this will have to wait post-Foxy release.
If we would have a "on parameter changed" callback, that could be used instead of a subscription (and it will be much cheaper).
My first reaction is to agree with @ivanpauno. That'd boost performance without introducing subtle issues with overall functionality.
I can understand that on resource constrained platforms one may want to drop unnecessary features (unnecessary for a given application), but I'm not convinced that's something you'd do in runtime.
@mauropasse
Benchmarks on RPi1 (single core running at 700Mhz) shows that CPU is reduced about 2% when this parameter event subscriber is not created.
just out of curiosity, only not creating subscription for parameter events lead this? I think cpu consumption for parameter event subscription depends on parameter activity.
@fujitatomoya I didn't do too much CPU profiling to get the exact reason, but my guess is that when IPC is used the subscription is implemented as a waitable, and the current StaticSingleThreadExecutor checks it's predicate at every iteration (IsReady?) Originally I did this to have a clean debug about the general system, setting ros params off, the subscription was still on and being checked.
If use_sim_time is modified locally, it will be ignored.
Maybe https://github.com/ros2/rclcpp/pull/1947 solves this issue, in which case I think adding this option will be fine.