xiangfu0 commented on PR #19273: URL: https://github.com/apache/pinot/pull/19273#issuecomment-5461553638
### Rebased exact-head JMH results Benchmarked source tree `e93f073930472994323aa3cfe5a9041b433f270f`, now published as exact PR head `843bf1496ddcd13ff79e26bb1d006e1c6f77fb7f` on base `bbbed251444e00d58bdcbe59a6f233902eb7e79c`. The published head and measured rebase have the same parent, tree, and stable patch ID. Environment: Apple M4 Pro (14 cores, 24 GB), OpenJDK 25.0.4, JMH 1.37, average time, one thread, two forks, two 1-second warmups, and five 1-second measurements. Allocation figures are from a separate one-fork `-prof gc` run. The primary numbers compare full-map and selective methods within the same exact-head build. | Workload | Access | Full | Selective | Speedup | Allocation | |---|---|---:|---:|---:|---:| | 64 entries, last key, flat | Object | 7.103 +/- 0.667 us/op | 0.697 +/- 0.043 us/op | 10.2x | 62,793 -> 6,136 B/op (-90.2%) | | 64 entries, last key, flat | String | 6.346 +/- 1.077 us/op | 0.712 +/- 0.062 us/op | 8.9x | 62,793 -> 5,552 B/op (-91.2%) | | 64 entries, last key, numeric | Object | 5.530 +/- 0.629 us/op | 0.626 +/- 0.121 us/op | 8.8x | 57,361 -> 3,664 B/op (-93.6%) | | 64 entries, last key, numeric | String | 6.265 +/- 0.409 us/op | 0.638 +/- 0.277 us/op | 9.8x | 57,417 -> 3,112 B/op (-94.6%) | | 64 entries, last key, nested | Object | 9.091 +/- 0.345 us/op | 0.772 +/- 0.053 us/op | 11.8x | 86,473 -> 7,136 B/op (-91.7%) | | 64 entries, last key, nested | String | 9.312 +/- 0.836 us/op | 0.853 +/- 0.189 us/op | 10.9x | 86,873 -> 7,536 B/op (-91.3%) | | 4 entries, first key, nested | Object | 0.549 +/- 0.006 us/op | 0.128 +/- 0.004 us/op | 4.3x | 5,536 -> 1,560 B/op (-71.8%) | | 4 entries, first key, nested | String | 0.584 +/- 0.006 us/op | 0.164 +/- 0.006 us/op | 3.6x | 5,936 -> 1,960 B/op (-67.0%) | For flat maps with the last key requested, object speedup grows from 3.9x at 4 entries to 7.8x at 16 entries and 10.2x at 64 entries. As a fallback control, I applied only the benchmark harness to `bbbed251`, leaving its production reader unchanged. Its selective methods therefore dispatch through the existing full-map defaults. Normalized allocation confirms the control: at 64 entries/last key, baseline full and selective allocations are effectively identical for every shape (flat object: 62,792.827 versus 62,792.835 B/op). The headline ratios above are same-head full-versus-selective comparisons, not cross-worktree timing ratios. The benchmark reuses one reader context and repeatedly reads the same LZ4 chunk. Decompression is warmed and cached before measurement, so these numbers measure hot-chunk row copy, key scan, and JSON work; they do not claim an improvement to cold-chunk decompression or I/O. The measured follow-up improvement points, kept out of this narrow PR, are: 1. Remove the complete-frame copy by exposing a bounded read-only row `ByteBuffer` to the sealed reader. The remaining selective allocation and the first-key scaling with map size point here first. 2. Return an offset/length or bounded slice for the matched value instead of allocating a second value `byte[]`. 3. After those copies are removed, optimize the byte-at-a-time/common-prefix key comparison; the growing first-key versus last-key gap isolates that scan cost. 4. Add a separate multi-row/multi-chunk PASS_THROUGH-versus-LZ4 benchmark before making any decompression claim. Post-rebase validation is green: 164 focused V4/V5/V6 and selective forward-index tests passed, plus Spotless, Checkstyle, license format/check, and `git diff --check` for `pinot-segment-local` and `pinot-perf`. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
