sunchao commented on a change in pull request #32407:
URL: https://github.com/apache/spark/pull/32407#discussion_r625437195
##########
File path: sql/core/benchmarks/FunctionBenchmark-jdk11-results.txt
##########
@@ -0,0 +1,32 @@
+OpenJDK 64-Bit Server VM 11.0.10+9-LTS on Mac OS X 10.16
+Intel(R) Core(TM) i9-10910 CPU @ 3.60GHz
+scalar function (long + long) -> long/notnull wholestage on: Best Time(ms)
Avg Time(ms) Stdev(ms) Rate(M/s) Per Row(ns) Relative
+-------------------------------------------------------------------------------------------------------------------------------------------
+with long_add_default 27292
29059 1913 18.3 54.6 1.0X
+with long_add_magic 7049
7070 20 70.9 14.1 3.9X
+with long_add_static_magic 6752
6791 67 74.1 13.5 4.0X
+
+OpenJDK 64-Bit Server VM 11.0.10+9-LTS on Mac OS X 10.16
+Intel(R) Core(TM) i9-10910 CPU @ 3.60GHz
+scalar function (long + long) -> long/notnull wholestage off: Best Time(ms)
Avg Time(ms) Stdev(ms) Rate(M/s) Per Row(ns) Relative
+--------------------------------------------------------------------------------------------------------------------------------------------
+with long_add_default 28601
28964 496 17.5 57.2 1.0X
+with long_add_magic 6986
7156 150 71.6 14.0 4.1X
+with long_add_static_magic 6509
6539 32 76.8 13.0 4.4X
Review comment:
So the reason for 1) is because `ApplyFunctionExpression` (especially
`BoundReference.eval` within the method) is quite expensive as it involves lots
of boxing and unboxing
<img width="1181" alt="Screen Shot 2021-05-03 at 3 47 22 PM"
src="https://user-images.githubusercontent.com/506679/116946667-99e08280-ac2f-11eb-91f7-1f2c3d728c57.png";>
This wasn't present in @cloud-fan 's benchmark.
For 2), there is another config `spark.sql.codegen.factoryMode` which
controls whether to do codegen on expressions (e.g., in projection). Therefore
even though whole stage codegen is turned off, underneath we are still calling
`Invoke.genCode` to execute the UDF. After turning
`spark.sql.codegen.factoryMode` off I'm seeing that the magic method is
actually half slower than the `produceResult` approach. Looking right now why
it is so much slower.
For 3) I think it is actually normal, apparently JIT does optimizations
which makes the performance almost the same in these two scenarios.
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
![https://user-images.githubusercontent.com/506679/116946667-99e08280-ac2f-11eb-91f7-1f2c3d728c57.png"](https://user-images.githubusercontent.com/506679/116946667-99e08280-ac2f-11eb-91f7-1f2c3d728c57.png"){kind=link}