Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Deserialization speedup proposal

Đang mở
  • Có gì không ổn?
#192 4 bình luận 3 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
c, python
Lĩnh vực
performance

Hướng nghiên cứu

Đọc các tệp được liên kết Example.msg, example_base.c, example.py, example_s.c và bench.py để hiểu cấu trúc C-extension được tạo theo đề xuất và benchmark. So sánh đề xuất đó với triển khai deserialization upstream, sau đó xác định liệu kiến trúc có chấp nhận được hay không và những bài kiểm thử cũng như phép đo hiệu năng nào sẽ xác định việc hoàn thành.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Feature request

Hello!
As already mentioned in other discussions python implementation has issues in serialization and deserialization performance(e.g. here). I focus on deserialization here.
I've tried some fixes on galactic branch and they look very promising for me: depending on message structure and size it's about 3-20 times faster. x3 for simple messages, up to x20 for complex types with high nesting level and array fields.

Feature description

The main idea is to avoid pure python code in message deserialization. To achieve it, every message is split into C extension base class and pure python derived class. C extension class contains all message fields, so deserialization method initializes C structure members without calling python methods. On the other hand pure python class contains all dunder methods and assertions.

Implementation considerations

Here is an example of how generated files look like for simple message file Example.msg:

_example_base.c extension module defines base class containing members of native types in lines 10-25.

Python module _example.py is the same as in upstream except for base class(line 62) and microoptimization of assertion in __init__ method(line 95).

Support extension module _example_s.c now uses specific subtype of PyObject(line 147), calls __new__ instead of __init__ to prevent pure python calls(line 170), directly initializes C typed fields of message(lines 188, 191) and creates nested collections (line 193-212).

Benchmark for this message which runs deserialization routine 1 million times gives 28 seconds vs 6,5 seconds

In case of more complex message like TestArrayComplex (from this issue) with 100 nested TestElement elements, the same benchmark gives 57,6 seconds vs 5,5 seconds for 50K deserializations.

I run benchmark with python3.8, ROS galactic, ubuntu 20.04, AMD 2,85GHz.

Pros:

  • performance improvement
  • public interface of message is not changed (as far as I can see)

Cons:

  • binary dependency for basic message operations(creation, reading/writing fields).
  • no more assertions while deserialization(I think it can be added)
  • initialization logic is duplicated in __init__ and *_convert_to_py methods.
  • compile time increased

I'm interested if this solution worth porting from my local galactic branch to upstream. Or may be it violates some ROS architecture principles.

Ngôn ngữ chính
EmberScript
Star
26
Fork
68
Merge trung bình
1 ngày 9 giờ
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ros2/rosidl_python

Tất cả issue của ros2/rosidl_python

Issue tương tự

Thêm issue về Performance

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.