abhishekrb19 commented on PR #19379: URL: https://github.com/apache/druid/pull/19379#issuecomment-5594130705
Benchmark 1 — transform mode comparison (unnestArraySize=5, 5×10s warmup + 10×10s measurement, 1 fork, 10k rows/op) ``` Benchmark (mode) (unnestArraySize) Mode Cnt Score Error Units TransformSpecBenchmark.transformRows NONE 5 avgt 10 0.542 ± 0.006 ns/op TransformSpecBenchmark.transformRows EXPRESSION 5 avgt 10 5.985 ± 0.113 ns/op TransformSpecBenchmark.transformRows SCAN_PASSTHROUGH 5 avgt 10 369.312 ± 9.751 ns/op TransformSpecBenchmark.transformRows SCAN_VC 5 avgt 10 1851.823 ± 61.218 ns/op TransformSpecBenchmark.transformRows SCAN_UNNEST 5 avgt 10 1061.146 ± 7.973 ns/op ``` Benchmark 2 — SCAN_UNNEST batch-size scaling (mode=SCAN_UNNEST, 5×10s warmup + 10×10s measurement, 1 fork, 10k rows/op) ``` Benchmark (mode) (unnestArraySize) Mode Cnt Score Error Units TransformSpecBenchmark.transformRows SCAN_UNNEST 5 avgt 10 963.466 ± 11.975 ns/op TransformSpecBenchmark.transformRows SCAN_UNNEST 20 avgt 10 2237.936 ± 17.684 ns/op TransformSpecBenchmark.transformRows SCAN_UNNEST 100 avgt 10 9156.740 ± 148.981 ns/op TransformSpecBenchmark.transformRows SCAN_UNNEST 1000 avgt 10 84573.609 ± 4139.941 ns/op ``` Relative ordering (fastest → slowest): NONE < EXPRESSION < SCAN_PASSTHROUGH < SCAN_UNNEST < SCAN_VC. The classic EXPRESSION transform is cheaper than any scan-based path: even a bare scan pipeline with no virtual columns or unnest (SCAN_PASSTHROUGH) costs more than EXPRESSION doing real work, and running that same expression through a scan virtual column (SCAN_VC) is the most expensive mode measured - more than SCAN_UNNEST. There's a real integration penalty from routing through the scan-query engine that likely has room to be optimized. For SCAN_UNNEST specifically, per-input-row overhead drops as the unnest array grows, since the fixed per-row cost (cursor reset, selector setup) amortizes over more output rows - wider arrays are cheaper per output row than narrow ones. Note: this benchmark isolates the transform stage only - it excludes Kafka fetch/poll, JSON parsing, and downstream indexing/persist, which are likely larger fixed costs per record in a real ingestion task. So these numbers are an upper bound on the transform stage's overhead, not a prediction of overall end-to-end throughput impact. The real-world impact may in fact be smaller, since Kafka I/O and other per-record costs are incurred regardless of transform mode and would dilute the relative overhead once folded into total per-record cost. -- 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]
