rich7420 commented on PR #6069: URL: https://github.com/apache/datafusion-comet/pull/6069#issuecomment-6036062947
Ran `CometSlidingSumBenchmark` at fbd8f7221 with a release build (`target-cpu=native`), Spark 3.5.9, JDK 17 and an 8 GB heap on an Apple M3 Pro. For 4M-row suffix frames, these are the ranges of mean timings across two independent JVM runs: | Input | DataFusion legacy SUM | Comet ANSI SUM | Comet TRY_SUM | |---|---:|---:|---:| | Positive, no NULLs | 709–736 ms | 512–546 ms | 522–529 ms | | Positive, 50% NULLs | 790–811 ms | 569–584 ms | 568–593 ms | | Near-limit, no NULLs | 744–749 ms | 571–581 ms | 565–580 ms | | All NULLs | 535–585 ms | 543–575 ms | 546–578 ms | The positive/no-NULL case was about 1.35–1.39× faster than legacy SUM. All-NULL results were similar. The additional 65,536-row bounded-frame run showed smaller, noisier differences between native implementations. All 112 timed cases completed, with the existing plan and `bit_xor`/`count` result assertions passing. Suffix validation compares 1,024 rows against Spark and all 4M rows between native implementations. These are end-to-end timings, not an isolated before/after measurement of the queue optimization; peak memory was not measured. All runs exited successfully; Maven `exec:java` emitted a Hadoop shutdown classloader warning after completion. -- 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]
