connortsui20 opened a new issue, #10587: URL: https://github.com/apache/arrow-rs/issues/10587
## Is your feature request related to a problem or challenge? Downstream crates built without LTO cannot inline `BitSliceIterator`'s hot path. The same path inlines within `arrow-buffer`, so the gap only appears across the crate boundary. [Vortex](https://github.com/vortex-data/vortex) discovered this gap while consuming `arrow-buffer` 58.4.0 from a separate crate (see https://github.com/vortex-data/vortex/pull/9259). `BitSliceIterator::next` is also the odd one out among its siblings in the same module. `BitIterator::next` already has `#[inline]`, and `BitIndexIterator::next` already has `#[inline(always)]`. ## Describe the solution you'd like Add `#[inline]` to these four methods: - `BitSliceIterator::new` - `BitSliceIterator::advance_to_set_bit` - `BitSliceIterator::next` - `UnalignedBitChunk::iter` 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 | 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. ## Describe alternatives you've considered Fat LTO also exposes the implementation to downstream optimization, but it requires consumers to change their build configuration. ## Additional context N/A -- 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]
