Uh oh!
There was an error while loading. Please reload this page.
[zstd_stream] Now use ZSTD_compressStream2 C API - #79
Conversation
If we can avoid an extra copy of the source data, don't copy. That will save the copy but also the allocation (which can be big on input)
Viq111
commented
Jan 31, 2020
To add content to that PR, I tried to reproduce the issue in #39 by writing a tool to stresstest CPU + memory (many workers, working close to OS memory limit) at a separate branch: https://github.com/DataDog/zstd/compare/viq111/mem_stresstest?expand=1 I wasn't able to reproduce it. My best guess is as this comment: #22 (comment) points out, there could be cases where the full input wouldn't be consumed, then in between calls that part of the memory is reused and edited. |
gmmeyer
left a comment
There was a problem hiding this comment.
This looks great! Thanks a lot for putting this together! :) I have a question about one of the lines.
Uh oh!
There was an error while loading. Please reload this page.
seiflotfy
commented
Feb 3, 2020
Great job on this! can we have it merged? |
Viq111
commented
Feb 3, 2020
Hi @seiflotfy Thanks for your interest! My current goal for merging this is end of this week / next week and do a pre-release from there. |
Viq111
commented
Mar 19, 2020
Sorry for the delay, I wanted to thoroughly check that we covered all cases. |
Based on comments from #22 & #39
This PR moves the stream compression C calls from the deprecated
ZSTD_compressBegin/ZSTD_compressContinueto the current stableZSTD_compressStream2APIIt allows piggy-back on #31 to do the same for the streaming interface
See https://github.com/facebook/zstd/blob/5120883a9c29a7966bbd2144df04f6976f4c7acc/lib/zstd.h#L576 for streaming best practices
(I'll do the Decompression API change in a separate PR to reduce the size of the PR and also technically the 2 changes can be made independently)