Methodology

Using rclcpp 32.0.0 (ROS 2 Lyrical) a PointCloud2’s payload lives in msg->data (a std::vector<uint8_t>). If the subscriber’s msg->data.data() is the same address the publisher held before publishing, the exact same heap buffer was handed over; true zero-copy. A different address means a deep-copy happened somewhere in the chain. A global operator new override was also implemented to count bytes allocated during the publish and dispatch window as a cross-check.

• Payload: 1.75 MiB (115k points × 16 byte point_step)
• One process, use_intra_process_comms(true), SingleThreadedExecutor, QoS depth 10 volatile.
• RMW during the run was rmw_cyclonedds_cpp, but the intra-process path is RMW-independent, so this does not affect any of the intra-process results; it only matters for cases [11]/[12] in the results.

Results

All message contents and results below are byte-identical across repeated runs.

Pattern A (fan-out / one-to-many)

Publisher make_unique and std::move; multiple subscribers take ConstSharedPtr. - Zero copies for any number of subscribers (case [7]). - Immune to a subscriber being added later, and to ros2 bag record / rviz attaching (case [12]). - Works with transient_local. - Cost: a consumer that needs to change the data must allocate a fresh output message; one allocation per frame, but still zero copies of the input. - Use for: anything observed by more than one node, anything recorded or visualised, latched topics, and any node that retains messages past the end of the callback (mergers, accumulators, sync buffers — ConstSharedPtr is cheap to store and shareable).

#include <memory>
#include <utility>

#include <rclcpp/rclcpp.hpp>
#include <sensor_msgs/msg/point_cloud2.hpp>

using PointCloud2 = sensor_msgs::msg::PointCloud2;

// ---- Producer -------------------------------------------------------------
// Allocate fresh, hand ownership to rclcpp, never touch the message again.
class CloudProducer : public rclcpp::Node
{
public:
  explicit CloudProducer(const rclcpp::NodeOptions & options)
  : rclcpp::Node("cloud_producer", options)
  {
    pub_ = create_publisher<PointCloud2>("cloud/input", rclcpp::SensorDataQoS());
  }

  void publish_frame()
  {
    auto msg = std::make_unique<PointCloud2>();
    fill(*msg);
    pub_->publish(std::move(msg));  // msg is null from here on
  }

private:
  rclcpp::Publisher<PointCloud2>::SharedPtr pub_;
};

// ---- Observer -------------------------------------------------------------
// Read-only. N of these cost nothing extra; all see the producer's buffer.
class CloudObserver : public rclcpp::Node
{
public:
  explicit CloudObserver(const rclcpp::NodeOptions & options)
  : rclcpp::Node("cloud_observer", options)
  {
    sub_ = create_subscription<PointCloud2>(
      "cloud/input", rclcpp::SensorDataQoS(),
      // ConstSharedPtr (or `const PointCloud2::ConstSharedPtr &`) is what makes
      // this a take_shared subscription. A mutable SharedPtr<T> would not.
      [this](PointCloud2::ConstSharedPtr msg) {
        RCLCPP_DEBUG(
          get_logger(), "buffer @ %p",
          static_cast<const void *>(msg->data.data()));

        // Retaining past the callback is free and safe under take_shared.
        latest_ = std::move(msg);
      });
  }

private:
  rclcpp::Subscription<PointCloud2>::SharedPtr sub_;
  PointCloud2::ConstSharedPtr latest_;
};

// ---- Transformer ----------------------------------------------------------
// Needs to change the data, so it allocates its own output. One allocation per
// frame; still zero copies of the input, and the output is itself Pattern A.
class CloudTransformer : public rclcpp::Node
{
public:
  explicit CloudTransformer(const rclcpp::NodeOptions & options)
  : rclcpp::Node("cloud_transformer", options)
  {
    pub_ = create_publisher<PointCloud2>("cloud/transformed", rclcpp::SensorDataQoS());
    sub_ = create_subscription<PointCloud2>(
      "cloud/input", rclcpp::SensorDataQoS(),
      [this](PointCloud2::ConstSharedPtr in) {
        auto out = std::make_unique<PointCloud2>();
        transform(*in, *out);  // e.g. a reprojection or a change of point type
        pub_->publish(std::move(out));
      });
  }

private:
  rclcpp::Publisher<PointCloud2>::SharedPtr pub_;
  rclcpp::Subscription<PointCloud2>::SharedPtr sub_;
};

Pattern B (in-place mutate-and-forward / linear pipeline)

Publisher make_unique and std::move, single subscriber takes UniquePtr, mutates the buffer it now owns, and republishes std::move(msg). - 0 copies and 0 allocations per hop — the same heap buffer travels the whole chain. This is strictly better than Pattern A, and it is the only way to get it. - Valid only while each hop has exactly one in-process consumer and no out-of-process subscriber.

// One in, one out, same buffer the whole way through.
class CloudFilter : public rclcpp::Node
{
public:
  explicit CloudFilter(const rclcpp::NodeOptions & options)
  : rclcpp::Node("cloud_filter", options)
  {
    pub_ = create_publisher<PointCloud2>("cloud/filtered", rclcpp::SensorDataQoS());
    sub_ = create_subscription<PointCloud2>(
      "cloud/input", rclcpp::SensorDataQoS(),
      // UniquePtr => take_ownership. We now own the producer's heap buffer.
      [this](PointCloud2::UniquePtr msg) {
        filter_in_place(*msg);
        pub_->publish(std::move(msg));  // same buffer continues downstream
      });
  }

private:
  // Compacts in place. Only ever shrinks `data`, so the vector never
  // reallocates and `data.data()` is preserved across the whole chain.
  static void filter_in_place(PointCloud2 & cloud)
  {
    const std::size_t stride = cloud.point_step;
    auto * base = cloud.data.data();
    std::size_t kept = 0;

    for (std::size_t i = 0; i < cloud.width * cloud.height; ++i) {
      const auto * src = base + i * stride;
      if (!keep(src)) {  // whatever your rejection criterion is
        continue;
      }
      auto * dst = base + kept * stride;
      if (dst != src) {
        std::memmove(dst, src, stride);
      }
      ++kept;
    }

    cloud.data.resize(kept * stride);  // shrink only; capacity is retained
    cloud.width = static_cast<uint32_t>(kept);
    cloud.height = 1;
    cloud.row_step = static_cast<uint32_t>(kept * stride);
    cloud.is_dense = true;
  }

  rclcpp::Publisher<PointCloud2>::SharedPtr pub_;
  rclcpp::Subscription<PointCloud2>::SharedPtr sub_;
};

The resize-down detail matters: growing data reallocates and you have quietly lost the zero-copy property while every address check still passes upstream of the growth. Pattern B only holds for pipelines that shrink or rewrite in place.

Default to Pattern A

Use Pattern B only on a genuinely linear, single-consumer chain where the per-hop allocation matters, and treat “exactly one consumer” as an invariant you have chosen to maintain, because nothing in rclcpp will tell you when it breaks.

Never Mix Ownership and Shared Subscribers on One Topic

Cases [8]/[9] are the worst topology from the test matrix: the shared group pays an extra allocate_shared(*message) on top of everything else. If a topic must serve both a mutator and observers, make everyone ConstSharedPtr and let the mutator allocate; or restructure so the mutator gets its own dedicated hop upstream and the observed topic is downstream-only. Note that with more than one consumer, in-place mutation is semantically impossible regardless, so ConstSharedPtr everywhere is not a compromise; it is the correct choice.

Never Use a Mutable shared_ptr<T> Callback

It is [[deprecated]] (any_subscription_callback.hpp:456), and it silently counts as an ownership subscription with none of UniquePtr’s benefits. Just don’t do it.

None of This Crosses a Process Boundary

Intra-process comms only apply within one process (thus the name), and publish-side loaning (borrow_loaned_message()) requires a bounded fixed-size type; PointCloud2’s unbounded data sequence disqualifies it on any RMW. So there is no zero-copy option between processes for clouds; the only solution for the case presented here is keeping the chain inside one process.

Found this useful or interesting?

Consider donating to support.

Any question, comments, corrections or suggestions?

Reach out on the social links below through the buttons.