yashmayya opened a new pull request, #17730: URL: https://github.com/apache/pinot/pull/17730
---
**Summary**
- Skip per-row convertTypes() in FunctionOperand.apply() when operand
types already match function parameter types
- At construction time, compare each operand's ColumnDataType against the
function parameter's ColumnDataType via FunctionUtils.getColumnDataType(). When
all match (the common case), set _needsConversion = false and bypass
convertTypes() in the hot path
- Add JMH benchmark (BenchmarkFunctionOperand) to measure the impact
---
**Motivation**
- The TODO on the original code noted: "Optimize per record conversion."
Every call to convertTypes() performs isAssignableFrom checks, HashMap lookups
(FunctionUtils.getArgumentType), and no-op PinotDataType.convert() calls per
argument per row, even when the Calcite planner has already ensured type
alignment.
---
**Benchmark Results**
```
Benchmark Mode Cnt Score
Error Units
BenchmarkFunctionOperand.invokeWithoutConvertTypes thrpt 5 0.166 ±
0.003 ops/us
BenchmarkFunctionOperand.invokeWithConvertTypes thrpt 5 0.041 ±
0.001 ops/us
BenchmarkFunctionOperand.applyTypesMatch thrpt 5 0.022 ±
0.001 ops/us
BenchmarkFunctionOperand.applyTypesNeedConversion thrpt 5 0.019 ±
0.009 ops/us
```
Isolated, skipping convertTypes() on matching types yields ~4x throughput
(0.166 vs 0.041 ops/μs). End-to-end in apply(), the improvement is ~15% as the
cost is diluted by toExternal(), reflection-based Method.invoke(), and
toInternal().
--
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]
