• Linux
• Linux-aarch64
• macOS
• Windows

Code size increase

Build type Debug

The size of the pybind11 version is almost 50 times bigger than master

master

$ ls -l _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so
-rw-r--r-- 1 sloretz sloretz 36608 Dec 22 14:54 _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so

this branch

$ ls -l _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so 
-rw-r--r-- 1 sloretz sloretz 1810720 Dec 22 14:52 _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so

Build type None

The size of the pybind11 version is a little over 13 times bigger than master

master

$ ls -l _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so
-rw-r--r-- 1 sloretz sloretz 17408 Dec 22 14:58 _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so

this branch

$ ls -l _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so
-rw-r--r-- 1 sloretz sloretz 232800 Dec 22 14:59 _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so

Build type Release

The size of the pybind11 version is a little over 5 times bigger than master

master

$  ls -l _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so
-rw-r--r-- 1 sloretz sloretz 17400 Dec 22 15:02 _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so

this branch

$ ls -l _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so
-rw-r--r-- 1 sloretz sloretz 93304 Dec 22 15:01 _rclpy_pycapsule.cpython-38-x86_64-linux-gnu.so

@azeey FYI

A 5 times code size increase (at best) seems like a lot for what is essentially a lateral move for this code. If you are using the Python bindings at all, code size and performance are probably not your top concern, but it is still very large. The question I have to ask is: given that we already have a working version of the hand-coded version of this library, does the move to pybind11 still make sense? That is, does the move have enough benefits that we are willing to take a 5-50 times increase in compiled code size?

I don't have a good answer for that, and I'll leave it to the maintainers of rclpy to answer. But I do think it should be considered.

does the move to pybind11 still make sense?

IMO, one of the biggest pain points of the current implementation is object lifetimes.
RCL objects may keep a reference of other rcl objects and then you need to destroy them in order, and when creating bindings to a garbage collected language that's a nightmare.

If we move to pybind11 and don't use capsules at all, pybind11 smart pointers support might make things a lot easier.

I'll also note that we could do a C++ implementation, and manage object lifetimes via C++ destructors - there's nothing forcing us to do a pure-c implementation as far as I can tell. If we created simple C++ wrapper objects for the CPython API objects - it would probably remove a lot of the lifetime management code. These might be easier to expose with pybind, as well.

Has it been considered to just selectively expose rclcpp to Python to implement rclpy functionality? This may have drawbacks I haven't considered.

Rebased on #667

I'll also note that we could do a C++ implementation, and manage object lifetimes via C++ destructors

@emersonknapp Definitely. Converting 1-to-1 is a hopefully quick process that will uncover any spots that are sensitive to pybind11's overhead. Using C++ and RAII comes after and adds a lot of benefit. You might be interested in the doc in #665.

CI (build: --packages-up-to rclpy test: --packages-select rclpy)

• Linux
• Linux-aarch64
• macOS
• Windows