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

When deploying a ROS 2 node that publishes at 1 Hz on a lightly loaded system, the intention is to lower CPU consumption by setting the publisher’s QoS profile to reliability: BEST_EFFORT and increasing the deadline to 500 ms, as the middleware then avoids retransmissions and drops late samples instead of buffering them.

Despite applying these QoS settings, measurements show the node’s CPU usage remains comparable to the default reliable configuration, raising uncertainty about whether the expected savings are realized, whether intra‑process communication would provide additional reduction, or whether stopping the ROS 2 daemon is required to observe any benefit.

What QoS combination actually yields measurable CPU savings for low‑frequency topics? Does intra‑process communication further reduce CPU load beyond the QoS tweaks? Is disabling the ROS 2 daemon necessary to see any power or CPU improvement on idle systems?