Optimize bit iteration and validity checking with SIMD popcount by robert3005 · Pull Request #8636 · vortex-data/vortex

Performance Gate Passed

⚡ 14 improved benchmarks
✅ 1588 untouched benchmarks
🆕 5 new benchmarks
⏩ 42 skipped benchmarks¹

	Mode	Benchmark	`BASE`	`HEAD`	Efficiency
⚡	Simulation	`slice_bounds[(16384, 0.1)]`	38.7 µs	3 µs	×13
⚡	Simulation	`slice_bounds[(16384, 0.9)]`	38.7 µs	3 µs	×13
⚡	Simulation	`slice_bounds[(4096, 0.1)]`	11.3 µs	2.2 µs	×5
⚡	Simulation	`slice_bounds[(4096, 0.9)]`	11.3 µs	2.2 µs	×5
⚡	Simulation	`many_indices[(16384, 0.1)]`	51.2 µs	16.3 µs	×3.1
⚡	Simulation	`many_indices[(16384, 0.9)]`	51.2 µs	16.3 µs	×3.1
⚡	Simulation	`many_indices[(4096, 0.1)]`	19.9 µs	14.8 µs	+34.44%
⚡	Simulation	`many_indices[(4096, 0.9)]`	19.9 µs	14.8 µs	+34.44%
⚡	Simulation	`filter_run_end[len=16384_run=16_density=0.9]`	87.8 µs	69.1 µs	+27.18%
⚡	Simulation	`filter_run_end[len=16384_run=16_density=0.5]`	88.2 µs	69.5 µs	+27.02%
⚡	Simulation	`filter_run_end[len=16384_run=16_density=0.1]`	89 µs	70.2 µs	+26.73%
⚡	Simulation	`filter_run_end[len=4096_run=16_density=0.5]`	27.9 µs	23 µs	+21.31%
⚡	Simulation	`filter_run_end[len=4096_run=16_density=0.9]`	27.9 µs	23 µs	+21.31%
⚡	Simulation	`bitwise_not_vortex_buffer_mut[128]`	273.6 ns	244.4 ns	+11.93%
🆕	Simulation	`for_each_set_index[(16384, 0.01)]`	N/A	8.4 µs	N/A
🆕	Simulation	`for_each_set_index[(16384, 0.1)]`	N/A	17.9 µs	N/A
🆕	Simulation	`for_each_set_index[(16384, 0.5)]`	N/A	56.3 µs	N/A
🆕	Simulation	`for_each_set_index[(16384, 0.9)]`	N/A	85.3 µs	N/A
🆕	Simulation	`for_each_set_index[(16384, 0.99)]`	N/A	89.8 µs	N/A

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

_{Comparing claude/bit-iterator-perf-0IMQ5 (e53eab2) with develop (b0d7e8c)²}

42 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. ↩
No successful run was found on develop (25b6b55) during the generation of this report, so b0d7e8c was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩