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

[configgrpc] create zstd.Decoder's using WithDecoderConcurrency(1) #10360

Closed
wants to merge 1 commit into from
Closed

[configgrpc] create zstd.Decoder's using WithDecoderConcurrency(1) #10360

wants to merge 1 commit into from

Conversation

mostynb
Copy link
Contributor

@mostynb mostynb commented Jun 6, 2024

Description

The zstd.Decoder documentation states:

It is important to use the "Close" function when you no longer need
the Reader to stop running goroutines, when running with default
settings. Goroutines will exit once an error has been returned,
including io.EOF at the end of a stream.

Streams are decoded concurrently in 4 asynchronous stages to give
the best possible throughput. However, if you prefer synchronous
decompression, use WithDecoderConcurrency(1) which will decompress
data as it is being requested only.

Since we store zstd.Decoder's in a sync.Pool, we should probably use WithDecoderConcurrency(1), so that we don't need to call Close() when they are dropped from the pool.

Link to tracking issue

Relates to #10323

Testing

TODO

The zstd.Decoder documentation states:
> It is important to use the "Close" function when you no longer need
> the Reader to stop running goroutines, when running with default
> settings. Goroutines will exit once an error has been returned,
> including io.EOF at the end of a stream.
>
> Streams are decoded concurrently in 4 asynchronous stages to give
> the best possible throughput. However, if you prefer synchronous
> decompression, use WithDecoderConcurrency(1) which will decompress
> data as it is being requested only.

Since we store zstd.Decoder's in a sync.Pool, we should probably use
WithDecoderConcurrency(1), so that we don't need to call Close()
when they are dropped from the pool.

Relates to #10323
@mostynb mostynb requested review from a team and bogdandrutu June 6, 2024 22:08
Copy link

codecov bot commented Jun 6, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.54%. Comparing base (a6ace53) to head (ec13060).

Additional details and impacted files
@@           Coverage Diff           @@
##             main   #10360   +/-   ##
=======================================
  Coverage   92.54%   92.54%           
=======================================
  Files         387      387           
  Lines       18254    18254           
=======================================
  Hits        16894    16894           
  Misses       1015     1015           
  Partials      345      345           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@songy23 songy23 left a comment

Choose a reason for hiding this comment

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

Looks like #10394 supersedes this PR since the internal fork of zstd is removed.

cc @jpkrohling

@mostynb mostynb closed this Jun 12, 2024
@mostynb mostynb deleted the zstd_decoder_concurrency branch June 12, 2024 21:27
@jpkrohling
Copy link
Member

Despite this being closed as not merged, I wanted to thank you for your time to open this PR here, @mostynb, and we appreciate the work you put also on the library we are using for gRPC payload compression.

@mostynb
Copy link
Contributor Author

mostynb commented Jun 13, 2024

No worries- you're welcome.

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.

3 participants