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 discovered this gap while consuming arrow-buffer 58.4.0 from a separate crate (see vortex-data/vortex#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::newBitSliceIterator::advance_to_set_bitBitSliceIterator::nextUnalignedBitChunk::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
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 withinarrow-buffer, so the gap only appears across the crate boundary.Vortex discovered this gap while consuming
arrow-buffer58.4.0 from a separate crate (see vortex-data/vortex#9259).BitSliceIterator::nextis also the odd one out among its siblings in the same module.BitIterator::nextalready has#[inline], andBitIndexIterator::nextalready has#[inline(always)].Describe the solution you'd like
Add
#[inline]to these four methods:BitSliceIterator::newBitSliceIterator::advance_to_set_bitBitSliceIterator::nextUnalignedBitChunk::iterA local reproduction on current
mainmeasured the proposed change with a separate consumer crate:#[inline]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