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

Consider allowing serialization into a Vec<u8> directly #44

Open
marshallpierce opened this issue Apr 6, 2017 · 0 comments
Open

Consider allowing serialization into a Vec<u8> directly #44

marshallpierce opened this issue Apr 6, 2017 · 0 comments

Comments

@marshallpierce
Copy link
Collaborator

Currently, serialization output is directed to a Write in both the V2 and V2 + DEFLATE serializers. This is a very flexible abstraction, but the serialization formats dictate a length prefix, which means that output must be buffered before writing to the writer so that we can drop in the final length in the appropriate spot.

This buffering is especially sad in the DEFLATE case, since we already have a Vec<u8> that will hold the uncompressed serialization, but we can only expose it to the underlying V2 serializer as a Write, so the uncompressed bytes get written to V2's buffer, then copied into V2 + DEFLATE's buffer, then compressed into another buffer, then written to the user-provided writer.

Some options:

  • Functions for Write or Vec<u8>, where the former buffers into an internal Vec<u8>
  • Functions for Write or Write + Seek. Need to benchmark this to see if it's measurably different from the Vec<u8> case. If it isn't, this seems preferable as it is more general.
  • Give up on Write and only serialize into either Write + Seek or a Vec<u8>. Maybe supporting I/O streams that don't seek is a sufficiently niche case that it's not worth creating an easy path for? On one hand, I really want to encourage people to use these formats as a wire protocol in a monitoring system. On the other hand, maybe such a protocol would use a container format like protobuf around the serialized histogram anyway, and it's a waste of API complexity budget to support simple Write usage.
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

No branches or pull requests

1 participant