Avoid unnecessary buffer zero-fill in Snappy decompression#9583
Avoid unnecessary buffer zero-fill in Snappy decompression#9583Dandandan wants to merge 1 commit intoapache:mainfrom
Conversation
Write directly into spare capacity instead of resize+zero-fill, eliminating unnecessary memset for the decompression output buffer. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
run benchmark arrow_reader_clickbench |
|
🤖 Arrow criterion benchmark running (GKE) | trigger |
|
🤖 Arrow criterion benchmark completed (GKE) | trigger Details
Resource Usagebase (merge-base)
branch
|
| let n = self | ||
| .decoder | ||
| .decompress(input_buf, &mut spare_bytes[..len]) | ||
| .map_err(|e| -> ParquetError { e.into() })?; |
There was a problem hiding this comment.
If this returns on error before setting len, will the buffer be left in an inconsistent state?
I think the use of the mut slice ensures that the call to decompress won't overwrite the newly allocated bytes.
However, this also basically passes in uninitialized bytes to decompress -- how do we know that the decompress doesn't read them? Maybe we should add a SAFETY warning to the decompress API that says it can't rely on initialized bytes 🤔
There was a problem hiding this comment.
Effectively we rely on this:
https://docs.rs/snap/latest/snap/raw/struct.Decoder.html#errors
- output has length less than decompress_len(input).
To not use unsafe we would need to have this feature:
BurntSushi/rust-snappy#62
|
run benchmark arrow_reader |
|
🤖 Arrow criterion benchmark running (GKE) | trigger |
Which issue does this PR close?
Closes #9579
Rationale
Currently, Snappy decompression uses
resize(len, 0)which zero-fills the buffer before writing. Since Snappy will overwrite the entire region on success, this memset is wasted work.1-2% win on snappy e2e decoding of snappy encoded parquet data
What changes are included in this PR?
Write directly into spare capacity using
reserve()+spare_capacity_mut()+set_len(), eliminating the unnecessary zero-fill.Are there any user-facing changes?
No.
🤖 Generated with Claude Code