Optimize copying during C++ and Rust data conversion.

[zhaohaidao]

Search before asking

• I searched in the issues and found nothing similar.

Description

Copying large blocks of data may cause performance bottlenecks. We should optimize the copying method if necessary.

Willingness to contribute

• I'm willing to submit a PR!

[Kelvinyu1117]

I would like to try that @zhaohaidao. I have took a look the PR #83. A rough idea is that The Datum should just hold the reference of the string_val and bytes_val if it is possible.

For string_val and bytes_val, we can use std::string_view and std::span (C++20) respectively.

[luoyuxia]

@Kelvinyu1117 Hi, sorry for missing your reply in this issue. @zhaohaidao What do you think of that?

[zhaohaidao]

we can use std::string_view and std::span (C++20) respectively.

@Kelvinyu1117 Hi, Kelvin, Thank you for your suggestion. Changing the type of string_val directly from std::string to std::string_view might have lifecycle issues, specifically:

1. from_ffi_datum receives const ffi::FfiDatum& ffi_datum (reference) and returns Datum (value).

2. ffi_datum.string_val is of type rust::String, and its underlying memory is managed by the Rust side.

3. After the function returns, the Datum will be held by the user, but the lifecycle of ffi_datum may have ended.

If you want to perform zero-copy optimization, I suggest exploring two approaches:

1. Leverage move semantics to transfer ownership. Specifically, transfer ownership of string_val from Rust to C++.

2. Explicitly introduce the free interface. When string_val is finished using, explicitly call the free interface to notify the Rust layer to release the relevant resources.

cc @luoyuxia

[fresh-borzoni]

@luoyuxia @zhaohaidao @Kelvinyu1117
Is there any progress on this?

If no, I may help here

[zhaohaidao]

@luoyuxia @zhaohaidao @Kelvinyu1117 Is there any progress on this?

If no, I may help here

No, I didn't put any effort into it. Please feel free to take it.

[fresh-borzoni]

Okay, then I'll help here 👍