There have been some performance issues uncovered in the behavior and assumptions made in the implementation of intraprocess communications. This is a meta-ticket to track improvements to intraprocess communications planned for D-turtle.

Tasks:

• Document talk between @mjcarroll and @wjwwood that describes current behavior and enumerates properties of various publisher/subscription types.
• Use rmw_count_matched_* to avoid publishing interprocess when a publication only has intraprocess subscriptions.
  • In the current system, a copy of the message must be made in order for both interprocess and intraprocess communications to have a copy that is owned by the respective system. Given the newly exposed subscription/publication count, this copy could be avoided.
  • This should be doable by checking the total subscription count vs the intraprocess subscription count.
  • Done in Added count matching api and intra-process subscriber count rclcpp#628
• Store unique or shared message in intraprocess manager based on publisher/subscription type.
  • In the current system, it is assumed that unique_ptr is used on both the publisher and subscription side. If the intraprocess manager was capable of storing shared_ptr, and subscriptions received shared_ptr (read only), then copies could be avoided in the case of multiple intraprocess subscriptions as well as mixed intra/interprocess subscriptions
  • Done in: New IntraProcessManager capable of storing shared_ptr<const T> rclcpp#690
• (stretch) offer "direct dispatch" (C++ only) - This would be similar to how ROS1 nodelets worked in that subscriptions could be directly invoked from the publication-side publish method. This is particularly useful in processing pipeline environments

Based on:

• Fix a bug when publishing unique_ptr rclcpp#504
• Intra-process communication latency demos#289

References:

• https://index.ros.org/doc/ros2/Tutorials/Intra-Process-Communication/