Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Deserialization speedup proposal

オープン
  • 何か問題がありますか？
#192 コメント 4 件 リアクション 3 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
c, python
領域
performance

調査の方向性

リンクされている Example.msg、example_base.c、example.py、example_s.c、bench.py を読み、提案されている生成 C 拡張の構造とベンチマークを理解してください。その提案を upstream のデシリアライゼーション実装と比較し、その上でアーキテクチャが受け入れ可能かどうか、また完了の基準となるテストとパフォーマンス測定は何かを明確にしてください。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
EmberScript
スター
26
フォーク
68
平均マージ
1日 9時間
マージ済み PR（30日）
3

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ros2/rosidl_python のほかの issue

ros2/rosidl_python の issue をすべて見る

似ている issue

Performance の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。