Don't copy contiguous bytes on reception

[fuzzypixelz]

This uses the slices iterator API of zenoh-c to avoid unecessarily copying bytes into an owned slice, if and only if the bytes is made up of exactly one slice.

[fuzzypixelz]

The aim of this pull request is to fix high latency for relatively large topics (e.g. 1 MB tagus) in the single-process iRobot benchmark with --ipc off. Results were obtained using the Mont Blanc topology on an Ubuntu 24.04.1 LTS machine with an Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz.

dd82e84

node	topic	size_b	mean_us	min_us	max_us
ponce	tagus	1000000	3016	2512	5705
geneva	tagus	1000000	3513	2997	6457
mandalay	tagus	1000000	2678	2214	5233

eed223a

node	topic	size_b	mean_us	min_us	max_us
ponce	tagus	1000000	1651	1363	2252
geneva	tagus	1000000	1875	1557	2563
mandalay	tagus	1000000	1390	1151	1867

eed223a + 401016c

node	topic	size_b	mean_us	min_us	max_us
ponce	tagus	1000000	393	257	1301
geneva	tagus	1000000	657	438	1701
mandalay	tagus	1000000	108	68	650

[clalancette]

Thanks for opening the PR.

We are just in the process of converting to zenoh-cpp as our API in #327. I'm assuming a similar idea will work there, but until we merge that, I'm going to mark this as a draft PR, and we can revisit it once we've merged that in.

[fuzzypixelz]

Thanks for opening the PR.

We are just in the process of converting to zenoh-cpp as our API in #327. I'm assuming a similar idea will work there, but until we merge that, I'm going to mark this as a draft PR, and we can revisit it once we've merged that in.

The bytes slice iterator API exists in zenoh-cpp, however there is no z_bytes_to_slice equivalent so we would need to manually allocate a buffer in that case or just use as_vector. We could coordinate potential changes to the zenoh-cpp API if necessary.

[clalancette]

All right, we've now merged in #327. Please rebase this and make any necessary changes to adapt to zenoh-cpp, and then we can do a full review of it.

[fuzzypixelz]

The following are updated benchmark results after switching from the C to the C++ Zenoh API.

df6ec26

node	topic	size_b	mean_us	min_us	max_us
ponce	tagus	1000000	1117	642	3399
geneva	tagus	1000000	1433	868	3775
mandalay	tagus	1000000	755	351	2807

bf7c354

node	topic	size_b	mean_us	min_us	max_us
ponce	tagus	1000000	629	402	2343
geneva	tagus	1000000	873	611	2674
mandalay	tagus	1000000	304	160	1943

[fuzzypixelz]

All right, we've now merged in #327. Please rebase this and make any necessary changes to adapt to zenoh-cpp, and then we can do a full review of it.

Should be ready for review now.

[clalancette]

Besides what I put inline, I'd also prefer not to have the implementation in the header file. That means that any downstream consumer has to compile the code all of the time. My suggestion is to just put this whole thing in the rmw_subscription_data.cpp file, but if you want to keep it a separate file then I'd suggest keeping just the API in the .hpp file and putting the implementation in a .cpp file.

[fuzzypixelz]

Besides what I put inline, I'd also prefer not to have the implementation in the header file. That means that any downstream consumer has to compile the code all of the time. My suggestion is to just put this whole thing in the rmw_subscription_data.cpp file, but if you want to keep it a separate file then I'd suggest keeping just the API in the .hpp file and putting the implementation in a .cpp file.

I will keep a separate translation unit for Payload as it might be useful for queries as well.

[YuanYuYuan]

A little suggestion: The Payload name seems to be too generic and we don't explain its behavior (which is a copy-on-write when making the bytes contiguous). Can we give it a proper name like CowPayload or CowBytes?

[fuzzypixelz]

79fc5ce seems to have broken the Jazzy build.