[fjmaco]

RoaringTreemap::select calls len() on each bitmap, which walks all of its containers, and then select() on the bitmap that holds the target, which walks them again. The last bitmap doesn't need the len() pass: RoaringBitmap::select already returns None when n is past its end.

This mostly helps treemaps whose values all fit in a u32. They have a single bitmap, so every select walked the whole bitmap before selecting. A select that lands in the last of several bitmaps also skips that bitmap's len() pass. The loop over the other bitmaps is unchanged.

Speedup of select (main time / branch time). Medians over 6 interleaved runs on a Ryzen 9 7900X pinned to two cores. Each side was built in 4 code layouts, and the brackets give the range over this branch's 4 layouts:

treemap	position	main	default flags	-C target-cpu=native
1 bitmap, 65536 array containers	1%	28.0 µs	74x [56-74]	103x [81-109]
	50%	42.0 µs	2.2x [1.7-2.2]	2.9x [2.5-3.0]
	last	57.6 µs	1.4x [1.1-1.4]	1.9x [1.6-2.3]
1 bitmap, 4096 bitmap containers	1%	1.8 µs	2.7x [2.7-2.7]	9.0x [8.9-9.1]
	50%	2.4 µs	2.5x [1.6-3.0]	3.0x [3.0-3.0]
	last	3.4 µs	1.5x [1.1-1.7]	1.9x [1.9-1.9]
1 bitmap, 8192 run containers	1%	85.5 µs	98x [98-99]	95x [94-96]
	50%	127 µs	3.0x [3.0-3.0]	3.0x [3.0-3.0]
	last	169 µs	2.0x [2.0-2.0]	2.0x [2.0-2.0]
4 bitmaps × 8192 run containers	last	427 µs	1.25x	1.25x
16 bitmaps × 4096 array containers	last	30.3 µs	1.03x	1.07x
100k bitmaps × 4 array containers	50%	232 µs	1.07x [1.06-1.08]	1.01x [0.97-1.12]
10k bitmaps × 16 array containers	50%	64.3 µs	0.99x [0.98-0.99]	0.98x [0.98-1.00]
1k bitmaps × 64 array containers	50%	19.8 µs	0.97x [0.95-1.00]	1.00x [1.00-1.01]

"Main" is with -C target-cpu=native. With many small bitmaps nothing changes algorithmically. Across 8 shapes with 1k–100k bitmaps of 1–64 containers each, at the 1%/50%/last positions, the results range from 0.97x to 1.18x. The slowest rows are within the ~3% spread I measured between differently laid-out builds of unchanged main.

I first tried a single pass over every bitmap, selecting while subtracting container lengths with no len() at all. It wins on few-bitmap treemaps, but on treemaps with 10k-100k small bitmaps it was slower in most builds I tried (up to about 1.6x) and moved a lot with code layout: len()'s plain sum seems to be cheaper than an early-exit loop when a whole bitmap is skipped. Keeping len() for all but the last bitmap avoids that. (An O(log n) select across bitmaps would need cached cardinalities; see the constant-time len work in #45, #105 and #182. This PR doesn't go there.)

The new property test checks select against the iterator for the first and last value of every bitmap plus random positions, including treemaps built with from_bitmaps that contain empty bitmaps.

Checked locally, with the RUSTFLAGS from test.yml:

• cargo fmt --all -- --check
• both clippy commands from test.yml on stable (1.99.0), beta, nightly and 1.90.0, plus nightly --all-features
• cargo test -p roaring --features serde and --no-default-features on stable, beta, nightly and 1.90.0
• cargo +nightly test -p roaring --features simd
• cargo test -p benchmarks --benches on stable, beta and nightly
• the CI miri job, plus the select/select_empty tests and the RoaringTreemap::select doctest under miri

This adds a test at the end of the same test module as #366, so whichever lands second needs a trivial rebase.

Happy to share the benchmark harness or turn it into a criterion bench if that's useful.

[Kerollmops]

Hey @fjmaco 👋

Thank you for the improvement. Unfortunately, I merged #366 as it was an old one and you seems to be able to quickly rebase on top of main as soon as you can 😅 Would you, please?

Have a nice day 🌵