Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

less allocate and memcpy in serialization #6

Open
wants to merge 3 commits into
base: v2.8
Choose a base branch
from
Open

Conversation

hicqu
Copy link

@hicqu hicqu commented Oct 20, 2020

By default there is an internal buffer in CodedOutputStream, which is always used when serializing a Message. It's useful when the output stream is a disk file or pipe. However if the output is an another memory buffer, redundant memcpy calls are involved.
This PR add a new method write_to_writer_without_buffer, which can avoid such buffer mechanism.

@hicqu hicqu changed the title Less alloc less allocate and memcpy in serialization Oct 20, 2020
/// Write the message to bytes vec.
fn write_to_vec(&self, v: &mut Vec<u8>) -> ProtobufResult<()> {
let size = self.compute_size() as usize;
if v.capacity() - v.len() < size {
v.reserve(size - v.len());
Copy link

Choose a reason for hiding this comment

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

I think something is off here. Does this function end up writing to the start of v or to v.len() - 1? It seems that line 115 assumes the latter and line 116 assumes the former.

@@ -56,12 +56,7 @@ pub trait Message: fmt::Debug + Clear + Any + Send + Sync {
/// Results in error if message is not fully initialized.
fn write_to(&self, os: &mut CodedOutputStream) -> ProtobufResult<()> {
self.check_initialized()?;

// cache sizes
self.compute_size();
Copy link

Choose a reason for hiding this comment

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

I think this is necessary?

Copy link
Author

Choose a reason for hiding this comment

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

No indeed. the cached internal size is not used later.

Signed-off-by: qupeng <[email protected]>
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