Repository navigation
Optimise in_list lookups for sparse integer sets - #10620
robert3005 wants to merge 6 commits into
Conversation
A set of a few dozen keys spread over a range of 100 000, such as the items DuckDB's join filters push into a fact table scan, was looked up by binary search, which mispredicts about half its comparisons. A bitmap of up to 128 KiB stays in the L2 cache and does not branch. TPC-DS SF10 q32, q16, q90 and q92 on DuckDB get 6-13% faster. Signed-off-by: Claude <noreply@anthropic.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011JxDQs8L3TZ6VhZV9Bt6cr (cherry picked from commit 4ccede3)
Add list_contains_set cases for i64 sets of 32 to 4096 values spread over spans of 2^24 and 2^40, too sparse for a bitmap. A roaring bitmap of the offsets was 1.6-2.1x slower than the binary search on all of them, since a lookup searches the containers and then an array container. Signed-off-by: Claude <noreply@anthropic.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011JxDQs8L3TZ6VhZV9Bt6cr (cherry picked from commit 6cc4d8b)
A prepared integer set decoded all of its needles into one array before looking them up, which for the 64Ki-row chunks of a scan writes a fresh buffer that has left the cache by the time it is read. Decode needles of other encodings in slices of 8192 rows and look each slice up while it is still in the cache. In TPC-DS q25, where the IN lists DuckDB pushes from joins took 15% of the query's CPU, this saves 7% of it. Signed-off-by: Robert Kruszewski <robert@spiraldb.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011JxDQs8L3TZ6VhZV9Bt6cr (cherry picked from commit 551eedd)
Signed-off-by: Robert Kruszewski <robert@spiraldb.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011JxDQs8L3TZ6VhZV9Bt6cr (cherry picked from commit eb80a26)
Reduction replaces the literal list of list.contains with a PreparedSet, which the falsifier did not recognise, so no IN list pruned any zone. Signed-off-by: Robert Kruszewski <robert@spiraldb.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011JxDQs8L3TZ6VhZV9Bt6cr (cherry picked from commit 76fcc23)
`execute_slice` does not exist, so slice each batch of needles and then execute it. Also move `NEEDLE_BATCH_LEN` to the top of the module, with the other constants. Signed-off-by: Robert Kruszewski <github@robertk.io> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Merging this PR will degrade performance by 8.9%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | WallTime | mul_u64_nonnull_neon |
20.5 µs | 39.3 µs | -47.83% |
| ❌ |
Simulation | test_scan_filter[int] |
3.1 ms | 3.6 ms | -14.92% |
| ❌ | WallTime | bitpack_blocked_compress_avx2 |
6.7 µs | 7.6 µs | -12.25% |
| ❌ | Simulation | take[routing/grouped_chunks/primitive/nonnull/chunks=32/indices=1000] |
386.5 µs | 429.6 µs | -10.05% |
| ⚡ | Simulation | chunked_opt_bool_canonical_into[(1000, 10)] |
65.7 µs | 54.9 µs | +19.84% |
| ⚡ | WallTime | threshold_avx512[80] |
2.9 µs | 2.6 µs | +11.78% |
| ⚡ | WallTime | filter_neon[8] |
979 ns | 882 ns | +11% |
| 🆕 | Simulation | i64_sparse_span_2_24[256] |
N/A | 173.8 µs | N/A |
| 🆕 | Simulation | i64_sparse_span_2_24[32] |
N/A | 99 µs | N/A |
| 🆕 | Simulation | i64_sparse_span_2_24[4096] |
N/A | 1.6 ms | N/A |
| 🆕 | Simulation | i64_sparse_span_2_40[256] |
N/A | 190.1 µs | N/A |
| 🆕 | Simulation | i64_sparse_span_2_40[32] |
N/A | 125.7 µs | N/A |
| 🆕 | Simulation | i64_sparse_span_2_40[4096] |
N/A | 1.6 ms | N/A |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing rk/prepared-set-ops (dea9546) with develop (5d8fa18)2
Footnotes
-
12 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(eafea78) during the generation of this report, so 5d8fa18 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
The bitmap lookup logic was very conservative, we can do better by expanding the
range