connortsui20 opened a new pull request, #10588: URL: https://github.com/apache/arrow-rs/pull/10588
## Which issue does this PR close? - Closes #10587. ## Rationale for this change Downstream crates built without LTO cannot inline the `BitSliceIterator` hot path. This change also makes `BitSliceIterator::next` consistent with the annotated `next` implementations on `BitIterator` and `BitIndexIterator`. [Vortex](https://github.com/vortex-data/vortex) discovered this gap while consuming `arrow-buffer` 58.4.0 from a separate crate. ## What changes are included in this PR? Adds `#[inline]` to `BitSliceIterator::{new, advance_to_set_bit, next}` and `UnalignedBitChunk::iter`. ## Are these changes tested? Yes. <details> <summary>Instruction-count measurements</summary> [Vortex's](https://github.com/vortex-data/vortex) original `arrow-buffer` 58.4.0 experiment measured 13,729 marginal instructions per iteration unmodified and 8,565 with fat LTO and one codegen unit. Annotating only `BitSliceIterator::next` reduced the count to 13,151, while annotating the broader pre-bisection set reduced it to 10,026. The bisection on current `main` narrows that set to the four methods in this PR. A local reproduction on current `main` measured the proposed change with a separate consumer crate: | Methods marked `#[inline]` | Marginal instructions per iteration | | ---------------------------- | -----------------------------------: | | None | 15,028 | | Four methods in this change | 7,584 | Removing any one of the four attributes gives up part of the improvement: | Method without `#[inline]` | Marginal instructions per iteration | | -------------------------------------------- | -----------------------------------: | | `BitSliceIterator::new` | 8,898 | | `BitSliceIterator::advance_to_set_bit` | 14,015 | | `BitSliceIterator::next` | 15,006 | | `UnalignedBitChunk::iter` | 8,448 | `UnalignedBitChunk::new` was also tested because it constructs this path. Adding it to the four-method set increases the result from 7,584 to 8,331 instructions, or 9.8%, so this PR does not annotate it. The consumer iterates contiguous true runs over a 16,384-bit buffer at 1% density. It uses `opt-level = 3`, 16 codegen units, and no LTO. Callgrind counts from runs of 1,000 and 2,000 iterations were differenced to remove startup and setup instructions. These are instruction counts, not wall-clock measurements. </details> On aarch64 macOS, the optimized `arrow-buffer` rlib changes from 1,799,592 to 1,808,184 bytes, an increase of 8,592 bytes or 0.48%. The median release compile time across five forced builds with warm dependencies remains 1.19 seconds. ## Are there any user-facing changes? No. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
