ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Zero-copy DDS Performance Comparison for RMW Providers in ROS 2

Hello ROS community!

Following the previous DDS middleware comparison on Windows platforms, today we bring you the performance comparison using zero-copy delivery.

This benchmark uses the Apex performance test tool to get latency results and maximum throughput in inter-process communications using Fast DDS and Cyclone DDS RMW implementations with zero-copy capabilities activated:

  • Fast DDS using data-sharing delivery.
  • Cyclone DDS using Iceoryx.

Testing limitations

Only results for Linux and reliable reliability are compared, since Cyclone+Iceoryx is not supported on Windows, and the RMW implementation of Cyclone DDS does not seem to support zero-copy for best-effort reliability. Note that these limitations do not apply to Fast DDS zero-copy.

Cyclone+Iceoryx has severe issues with data rates over 1,000 messages per second. Shortly after launching the processes, it complains that the mempool has no more available chunks. We tried increasing the number of chunks, with no improvement. The result is that the maximum throughput is very poor compared to Fast DDS, especially for large data sizes.

The Iceoryx daemon iox-roudi crashed several times during the batch execution of the tests, invalidating the remaining test cases of the batch. This was easily resolved repeating the affected tests, but proves the problem of having a single point of failure that completely disables the zero-copy delivery.




These results confirm that Fast DDS implementation of the zero-copy delivery has the best performance and robustness among the open source DDS implementations for ROS 2! Especially with large data sizes, it performs considerably better in both latency and throughput.

eProsima will shortly publish the complete workbench description and results on its website, so stay tuned!


We tried increasing the number of chunks up to 50,000 on iceoryx, but it did not help. This number of chunks will already cause allocation problems on 4MB messages on most systems, but even for the 256B case it complained of no available free chunks.

1 Like