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

Zstd support for compression #1170

Merged
merged 4 commits into from
Oct 1, 2018
Merged

Zstd support for compression #1170

merged 4 commits into from
Oct 1, 2018

Conversation

bobrik
Copy link
Contributor

@bobrik bobrik commented Sep 18, 2018

KIP-110 is finally accepted, so I can make a PR with something we've been using for quite a while now.

cc @dqminh, @andrew-plunk

@bai
Copy link
Contributor

bai commented Sep 22, 2018

Thanks for contributing this. Could we add some tests, similarly to how lz4 is tested?

@bobrik
Copy link
Contributor Author

bobrik commented Oct 1, 2018

@bai good point. I started looking into that and hit DataDog/zstd#41.

bobrik and others added 4 commits September 30, 2018 17:34
Decompress guess the size first then decompress so generally it takes much
less allocation than iotuil.ReadAll which used a fixed buffer size of 512 bytes
when message size is larger than 512 bytes.

Creating ztsd.Reader for small messages is also costly because it
has to perform additional cgo calls to initialize the context, compare to just 2
cgo call to decompress with a nil dst slice.

Samething apply for Compress, it saves some cgo calls, and we dont reuse the writers anyway.
@bobrik
Copy link
Contributor Author

bobrik commented Oct 1, 2018

I've updated the PR with tests and a workaround for zero sized messages.

@bai bai merged commit 6bfdd61 into IBM:master Oct 1, 2018
@bai
Copy link
Contributor

bai commented Oct 1, 2018

❤️

@lizthegrey
Copy link
Contributor

This patch does not appear to actually work in practice without also incrementing the version of the producer and consumer protocol messages beyond 3 and 4 to 7 and 9, respectively. However, there are potentially breaking spec changes (even if not field/proto changes) in the intermediate versions we'd be skipping over.

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.

4 participants