experiment with the SymBuf representation

[folkertdev]

@brianpane you might enjoy playing around with this.

I get some actual speedup for compression level 3, it appears to be pretty neutral for the others. In zlib-ng, they actually use 2 arrays, which I did try but only gave instruction count improvements, not cycles/wall time.

I think the padding field is important because it makes initialization as just all zeros possible, which is efficient for the fill operations.

but well there is still the ordering of the fields, maybe #[repr(packed)] is useful, and maybe there are other ideas still.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Flag	Coverage Δ
fuzz-compress	40.82% <96.00%> (-0.01%)	⬇️
fuzz-decompress	30.76% <0.00%> (+0.07%)	⬆️
test-aarch64-apple-darwin	92.37% <100.00%> (+<0.01%)	⬆️
test-x86_64-apple-darwin	91.59% <100.00%> (-0.01%)	⬇️
test-x86_64-unknown-linux-gnu	90.22% <100.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
zlib-rs/src/deflate.rs	97.02% <100.00%> (ø)
zlib-rs/src/deflate/pending.rs	97.01% <ø> (ø)
zlib-rs/src/deflate/sym_buf.rs	98.11% <100.00%> (+1.68%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[folkertdev]

the https://github.com/trifectatechfoundation/zlib-rs/tree/sym-buf-experiment branch has some further experiments. I can't really pin it down and get conclusive improvements.

[brian-pane]

Sorry for the delay in looking at this. I just tried this patch on my test system (Intel x86_64), and the performance was basically the same as the baseline there too.