xiangfu0 commented on PR #19568:
URL: https://github.com/apache/pinot/pull/19568#issuecomment-5803280263

   **Benchmark results updated** — and one claim in the original description 
was overstated, so flagging it rather than editing silently.
   
   The old table (a one-off micro-benchmark from before review) claimed roughly 
2x on both encode and decode. I replaced it with 
`BenchmarkSegmentListEncoding`, now in `pinot-perf` in this PR, which drives 
the real `QueryPlanSerDeUtils` paths and separates build, build plus serialize, 
and decode. The corrected picture, per leaf-stage worker:
   
   | 60k segments | JSON | proto | |
   |---|---:|---:|---|
   | build (used to run on the compile executor) | 15.0 MB, 2.1–4.8 ms | 0.74 
MB, 120–454 µs | **−95% alloc, ≥10x faster** |
   | dispatch total (build + serialize) | 22.6 MB, 5.2–10.1 ms | 9.3 MB, 
4.9–5.8 ms | **−59% alloc; time parity–2x** |
   | server decode | 10.9 MB, 3.2–5.6 ms | 7.5 MB, 823–845 µs | **−31% alloc, 
4–6x faster** |
   
   - **Allocation is deterministic** (`-prof gc`, identical across runs); times 
are ranges over three runs on a shared machine with a load average of 11–19 on 
14 cores, which is why they move so much. 100k segments follows the same 
pattern.
   - **The correction:** the dispatch-side encode is *not* a reliable 2x. 
Serializing tens of thousands of individually length-prefixed strings costs 
about as much as one large JSON string, so the broker-side time win ranges from 
none to 2x at 60k, though it always allocates less than half as much. Decode is 
the strong side.
   - **The compile-path win is independent of the flag:** the JSON build, at 
least 2.1 ms per worker at 60k, is off the query-compile executor for every 
query now.
   - **Tried and rejected:** pre-encoding each segment name into a `ByteString` 
so protobuf's size computation and write become byte copies. Identical wire 
bytes, but slower (5.8 ms vs 4.9 ms) and 16% more allocation, from the 
per-segment wrapper objects.
   - Wire size is within 1.6%, so this is a CPU and allocation change, not a 
bandwidth one.
   
   Full tables and the reproduce command are in the description's Benchmark 
section.


-- 
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]

Reply via email to