Unexpected CPU usage persists with BEST_EFFORT QoS and 500 ms deadline on low‑traffic ROS 2 topic

The short answer

For a 1 Hz topic on a lightly loaded system, almost all CPU time is spent in your own subscription callbacks and node housekeeping, not in DDS retransmission logic. That is why switching from RELIABLE to BEST_EFFORT shows no measurable difference: at one message per second, the reliable path rarely retransmits anything, so there is nothing to save. Extending the deadline to 500 ms only relaxes the liveness check the middleware performs; it does not reduce the work done per sample. It can, however, delay detection of missed samples, so a long deadline is a correctness trade-off, not a performance knob.

What actually reduces CPU here

• Intra-process communication: when the publisher and subscriber live in the same process, enabling intra-process delivery skips serialization and the transport stack entirely. For a 1 Hz topic this commonly yields on the order of 10–30% lower node CPU, with the exact figure depending on payload size and the DDS vendor (Fast DDS vs Cyclone DDS). Treat that range as an expectation to verify, not a guarantee.
• Stopping the ROS 2 daemon: not necessary. The daemon only handles discovery and graph queries; on an idle single-machine setup its CPU cost is negligible, and disabling it will not produce a visible power or CPU improvement. Leave it running unless you have a specific discovery-related reason to remove it.

Steps for this specific case

1. Confirm the rate and that a subscriber is actually attached: ros2 topic hz /topic_name and ros2 topic info /topic_name.
2. Record a CPU baseline with top -p $(pgrep -f my_node) under the default reliable QoS.
3. Apply the BEST_EFFORT profile and re-measure. Expect no significant change — that confirms the diagnosis rather than indicating a misconfiguration.
4. If publisher and subscriber can share a process, enable intra-process (in rclcpp, pass rclcpp::NodeOptions().use_intra_process_comms(true)) and measure again. This is where the real saving appears.
5. Optionally run with DDS debug logging to confirm no retransmissions occur under BEST_EFFORT, validating that reliability was never the cost driver.

Caveats and assumptions

This behavior is well established for ROS 2 Foxy through Humble; newer distributions may change middleware CPU profiles, so re-measure after upgrades. Small QoS-related savings can be masked by other timers or callbacks in the same node — isolate the publisher/subscriber pair for a clean measurement. Intra-process only helps when both endpoints share a process; cross-process subscribers see no benefit.

One detail that changes the recommendation

Are your publisher and subscriber currently in the same process? If they are separate processes, intra-process is unavailable and the only realistic path to lower CPU is reducing per-callback work (cheaper deserialization, less logging, or fewer allocations in the callback), since QoS tuning at 1 Hz will not move the needle.