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

github.com/klauspost/compress for snappy #10

Open
jzelinskie opened this issue Jun 30, 2022 · 8 comments
Open

github.com/klauspost/compress for snappy #10

jzelinskie opened this issue Jun 30, 2022 · 8 comments

Comments

@jzelinskie
Copy link

Hey there!

I noticed that this library doesn't use the snappy library from klauspost/compress, but it does import this library for zstd.
A cursory look makes it appear to be faster. Is there a reason why you aren't using it? Is it worth a PR?

@mostynb
Copy link
Owner

mostynb commented Jun 30, 2022

Hi, I'm not as familiar with snappy compared to lz4 and zstd. I'd be happy to switch if you benchmarked and found @klauspost's implementation faster though.

@klauspost
Copy link

It can either be faster or compresses more and sometimes both.

https://github.com/klauspost/compress/tree/master/s2#snappy-compatibility

Replace snappylib "github.com/golang/snappy" -> github.com/klauspost/compress/s2. If you don't want options snappylib github.com/klauspost/compress/snappy.

	c.poolCompressor.New = func() interface{} {
		w := s2.NewWriter(ioutil.Discard, s2.WriterSnappyCompat())
		return &writer{Writer: w, pool: &c.poolCompressor}
	}

Options to consider: WriterBetterCompression gives better compression. WriterConcurrency(1) if you want to disable multithreaded compression.

	if !inPool {
		newR := s2.NewReader(r, s2.ReaderMaxBlockSize(64<<10))
		return &reader{Reader: newR, pool: &c.poolDecompressor}, nil
	}

@mostynb
Copy link
Owner

mostynb commented Jun 30, 2022

If we were to add s2, I think that should be registered with the grpc framework under the name "s2" instead of "snappy" for compatibility reasons.

@klauspost
Copy link

Yeah, adding it as a separate option would be nice (and trivial)

FWIW here is a comparison of different types: https://twitter.com/sh0dan/status/1532298056082804736

@mostynb
Copy link
Owner

mostynb commented Jul 6, 2022

@klauspost: re s2, if I use WriterConcurrency(1) can I safely put s2.Writer's in a sync.Pool without leaking memory?

@klauspost
Copy link

@mostynb You can do that either way. It does not keep goroutines active.

@mostynb
Copy link
Owner

mostynb commented Jul 7, 2022

OK, it's just that the s2.NewWriter docs say that resources might not be released if Close isn't called (as would happen with sync.Pool):

Users must call Close to guarantee all data has been forwarded to the underlying io.Writer and that resources are released. They may also call Flush zero or more times before calling Close.

@mostynb
Copy link
Owner

mostynb commented Jul 24, 2022

@jzelinskie: I created a PR which you can experiment with if you like: #12.

mostynb added a commit that referenced this issue Jul 25, 2022
…ent than the google snappy package

Relates to #10.
mostynb added a commit that referenced this issue Jul 25, 2022
…ent than the google snappy package

Relates to #10.
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

3 participants