Skip to content

Generate separate mod files in the ros2 msg-gen for better compiling time#1182

Merged
phil-opp merged 10 commits intodora-rs:mainfrom
drindr:ros-msg
Nov 9, 2025
Merged

Generate separate mod files in the ros2 msg-gen for better compiling time#1182
phil-opp merged 10 commits intodora-rs:mainfrom
drindr:ros-msg

Conversation

@drindr
Copy link
Copy Markdown
Contributor

@drindr drindr commented Nov 5, 2025

This PR generate separate mod files for ros2 msg and reduce the cross-reference between mods.

Tested on my laptop with --timings flag, the 1st compiling time of dora-ros2-bridge is 2~3 secs slower than the single file implementation.
And as I source a new ros2 interfaces package, with incremental compiling, the compiling time is 6~8 secs faster than the original one.

The change of code-generate time is less than 1 sec according to the report.

In the 1st compilation, I just source the system's ros2 workspace.
In the 2nd compilation, I add a new customize interface package.
In the 3rd compilation, I remove the customize interface package added in the 2nd compilation.

single file multi-file
1st 35.19s 38.19s
2nd 35.45s 29.12s
3rd 37.02s 28.8s

And for c++ users, they can just compile and include the specific header they need, which increases the complexity (more flags) but can reduce the c++'s compiling time (not tested yet).

The compiling time of ros2-bridge is still very long. I'm not sure if it's still worthy to push ahead.

divide msgs from different packages into different files to
take advantage of rust's incremental compiling.

Signed-off-by: drindr <dreamchancn@qq.com>
use separate package mod for cxx api

Signed-off-by: drindr <dreamchancn@qq.com>
Signed-off-by: drindr <dreamchancn@qq.com>
Signed-off-by: drindr <dreamchancn@qq.com>
Signed-off-by: drindr <dreamchancn@qq.com>
the alias have been moved into the mod.
the hand-writing mod block can be removed.

Signed-off-by: drindr <dreamchancn@qq.com>
Signed-off-by: drindr <dreamchancn@qq.com>
Signed-off-by: drindr <dreamchancn@qq.com>
Copy link
Copy Markdown
Collaborator

@phil-opp phil-opp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot! I haven't had time for a in-depth review, but this seems like a nice improvement. The generated files and the separation into different modules certainly looks much cleaner now. I also did some basic tests and everything seems to be still working as expected.

@phil-opp
Copy link
Copy Markdown
Collaborator

phil-opp commented Nov 7, 2025

Could you resolve the conflicts with main please? Then we can merge.

The compiling time of ros2-bridge is still very long.

Yes, it is. It's been a while since I wrote the code so I don't remember what part of the compilation requires most time. Is it just the amount of Rust code that is generated or is the bottleneck somewhere else?

Signed-off-by: drindr <dreamchancn@qq.com>
@phil-opp phil-opp merged commit 8b9a7a9 into dora-rs:main Nov 9, 2025
27 checks passed
@phil-opp
Copy link
Copy Markdown
Collaborator

phil-opp commented Nov 9, 2025

Thanks again!

@drindr
Copy link
Copy Markdown
Contributor Author

drindr commented Nov 9, 2025

Is it just the amount of Rust code that is generated or is the bottleneck somewhere else?

The bottleneck is from the dora-node-api-cxx crate with generated msg code. The compiling time of c++ API without ros2-brdige feature is less than 1 sec, while the one with ros2-bridge costs even more than 30s.

The dora-ros2-bridge crate without C++ API is near 6s, so I think most of the compiling time is used by the Rust compiler to process the generated code about ROS2's messages.
I do not know if there is a way to optimize it because the code-generate procedure is limited to the interior of a single crate.

@phil-opp
Copy link
Copy Markdown
Collaborator

Thanks for the info!

Could you also time a build of the dora-ros2-bridge crate? If this is considerably faster, the overhead might also come from the linker.

I also just noticed that cargo seems to rebuild the dora-node-api-cxx crate every time, even if nothing changed. That shouldn't be. I look into it.

@phil-opp
Copy link
Copy Markdown
Collaborator

I also just noticed that cargo seems to rebuild the dora-node-api-cxx crate every time, even if nothing changed. That shouldn't be. I look into it.

One part of the issue was a recent change in the cxx-build crate: dtolnay/cxx#1462. This should be fixed with dtolnay/cxx#1668.

I opened #1189 to fix this (and also remove another incorrect rerun-if-changed.

@drindr
Copy link
Copy Markdown
Contributor Author

drindr commented Nov 12, 2025

I apply the same 2 timing process mentioned before for the crate dora-ros2-bridge

The change of code-generate time is less than 1 sec according to the report.

In the 1st compilation, I just source the system's ros2 workspace. In the 2nd compilation, I add a new customize interface package. In the 3rd compilation, I remove the customize interface package added in the 2nd compilation.

The result is

single multi
1st 4.86s 4.83s
2nd 5.04s 3.82s

phil-opp added a commit that referenced this pull request Nov 12, 2025
- Update `cxx` crate to 1.0.188 to include
dtolnay/cxx#1668
- Remove `rerun-if-changed` for autogenerated file (which always caused
rebuild)
- Rerun build script if the `DORA_NODE_API_CXX_INSTALL` env variable
changes

Discovered in
#1182 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants