andygrove opened a new pull request, #5118: URL: https://github.com/apache/datafusion-comet/pull/5118
## Which issue does this PR close? Part of #5112. ## Rationale for this change The isolated columnar-to-row benchmark added in #5113 only measures one schema (long, int, double, string), which is close to the JVM path's best case: every accessor is allocation-free or escape-analyzable, and the schema contains a var-length column so the native converter is forced onto its slower row-at-a-time path. Real workloads such as TPC-H reach C2R with very different schemas, and cluster results there can favor the native converter even though this benchmark says otherwise. The benchmark needs to cover the schema dimensions that decide which implementation wins. ## What changes are included in this PR? Parameterizes `CometC2RIsolatedBench` over schema scenarios, sweeping each at batch sizes 8192, 512, and 32: - long, int, double, string (the original baseline) - 4 x decimal(12,2), date, 2 x string (TPC-H lineitem-like; the JVM accessor allocates a `Decimal` per value) - 4 x decimal(12,2), date, long (all fixed-width, which engages the native column-wise fast path) - 2 x decimal(38,10), long (high precision; the JVM accessor allocates a byte[], `BigInteger`, java `BigDecimal`, scala `BigDecimal`, and `Decimal` per value) - 16 x long (wide primitives) Also reports JVM heap bytes allocated per row for each path via `ThreadMXBean.getThreadAllocatedBytes`, since the two implementations have very different allocation profiles that an idle-heap microbenchmark's wall-clock numbers do not surface: the JVM path allocates per object-typed value but reuses its output row buffer, while the native path allocates a `byte[]` plus `UnsafeRow` per row for the defensive copy added in #3367. Results on Apple M3 Ultra, Spark 4.1 (per-row ns, best time; allocation in JVM heap bytes per row at batchSize=8192): | Scenario | JVM 8192 | Native 8192 | JVM 32 | Native 32 | JVM alloc B/row | Native alloc B/row | |---|---|---|---|---|---|---| | long, int, double, string | 8.5 | 32.7 | 16.5 | 309.9 | 24.1 | 100.0 | | 4 x decimal(12,2), date, 2 x string | 35.5 | 52.6 | 45.9 | 518.6 | 131.2 | 120.8 | | 4 x decimal(12,2), date, long (all fixed-width) | 20.4 | **16.7** | 30.7 | 451.0 | 152.2 | 146.0 | | 2 x decimal(38,10), long | 58.7 | 70.5 | 73.6 | 310.5 | 392.1 | 137.0 | | 16 x long | 23.7 | 31.4 | 36.5 | 966.3 | 24.5 | 228.5 | The all-fixed-width decimal scenario is the first case where the native converter wins outright, and the decimal scenarios show the JVM path allocating up to 3x more heap per row, a cost that is mostly invisible on an idle benchmark heap but real on a loaded executor. ## How are these changes tested? Ran `make benchmark-org.apache.spark.sql.benchmark.CometC2RIsolatedBench` twice; results above are from the second run and the baseline scenario reproduces the numbers reported in #5112. -- 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]
