perf(buffer): read byte-aligned bit operands directly as words

[miniex]

Summary

Split out of #8425 so each perf change can be looked at on its own, as suggested by @joseph-isaacs. This is the "bit collect" half, no count fusion.

bitwise_binary_op only took the direct word path when both operands were 64-bit aligned, otherwise falling back to iter_padded. It now reads the backing bytes as u64 via as_chunks::<8> for any byte-aligned offset, leaving iter_padded for sub-byte offsets only. This also drops the from_trusted_len_iter unsafe for a safe BufferMut push.

Testing

cargo test -p vortex-buffer passes, plus a per-bit reference test (binary_op_matches_naive) across operand offsets and lengths. It also passes under miri (strict provenance). fmt + clippy --all-targets --all-features clean.

---

I'm Korean, so sorry if any wording reads a little awkward.

[codspeed-hq]

Merging this PR will improve performance by 24.7%

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 13 improved benchmarks
❌ 3 regressed benchmarks
✅ 1529 untouched benchmarks
⏩ 10 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	chunked_bool_canonical_into[(1000, 10)]	20.4 µs	35.6 µs	-42.6%
❌	Simulation	chunked_varbinview_canonical_into[(1000, 10)]	161.6 µs	198 µs	-18.38%
❌	Simulation	chunked_varbinview_into_canonical[(1000, 10)]	176.6 µs	213 µs	-17.1%
⚡	Simulation	bitwise_and_vortex_buffer[65536]	24.3 µs	15.1 µs	+60.89%
⚡	Simulation	bitwise_or_vortex_buffer[65536]	24.3 µs	15.2 µs	+60.08%
⚡	Simulation	bitwise_and_vortex_buffer[2048]	4.4 µs	2.9 µs	+50.81%
⚡	Simulation	bitwise_and_vortex_buffer[1024]	4.1 µs	2.8 µs	+48.06%
⚡	Simulation	bitwise_and_vortex_buffer[16384]	9.9 µs	6.7 µs	+47.62%
⚡	Simulation	bitwise_or_vortex_buffer[16384]	9.9 µs	6.8 µs	+46.14%
⚡	Simulation	bitwise_or_vortex_buffer[1024]	4 µs	2.8 µs	+45.94%
⚡	Simulation	bitwise_or_vortex_buffer[2048]	4.3 µs	3 µs	+45.88%
⚡	Simulation	bitwise_and_vortex_buffer[128]	4.7 µs	3.4 µs	+38.44%
⚡	Simulation	bitwise_or_vortex_buffer[128]	4.7 µs	3.4 µs	+36.41%
⚡	Simulation	bitwise_not_vortex_buffer_mut[128]	273.6 ns	215.3 ns	+27.1%
⚡	Simulation	bitwise_not_vortex_buffer_mut[1024]	333.9 ns	275.6 ns	+21.17%
⚡	Simulation	bitwise_not_vortex_buffer_mut[2048]	456.9 ns	398.6 ns	+14.63%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing miniex:perf/bit-collect (d1786df) with develop (e935986)}

Footnotes

1. 10 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[joseph-isaacs]

Suggested change

	// bytes straight as words instead of shifting through `iter_padded`.
	if left.offset().is_multiple_of(8) && right.offset().is_multiple_of(8) {
	// bytes straight as words instead of shifting through `iter_padded`.
	// TODO(joe): make this into an iterator.
	if left.offset().is_multiple_of(8) && right.offset().is_multiple_of(8) {

Can you add a todo to make this into an iterator

[joseph-isaacs]

Or maybe do this?

[joseph-isaacs]

I think this will make LLVM generate better code

[miniex]

ok, i check it!

[joseph-isaacs]

I just merged in a fix to another crate from develop

[miniex]

done, made it a TrustedLen iterator

[joseph-isaacs]

I was talking about the input too, You really have found the difference between an aligned and unaligned byte iterator. Lets land this and maybe we can have a follow up

[joseph-isaacs]

Thanks for this. I wonder if we can work this into an iterator left and right without a perf loss?

[miniex]

Thanks for this. I wonder if we can work this into an iterator left and right without a perf loss?

thanks for merging! lets dig into that in a follow up.

also #8425 is the collect+count half stacked on this. i'll rebase it onto develop now that this landed so it's just the fuse, then it's ready for review.