Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -577,10 +577,10 @@ object SQLConf {
.doc("The maximum lines of a single Java function generated by whole-stage codegen. " +
"When the generated function exceeds this threshold, " +
"the whole-stage codegen is deactivated for this subtree of the current query plan. " +
"The default value 2667 is the max length of byte code JIT supported " +
"for a single function(8000) divided by 3.")
"The default value 4000 is the max length of byte code JIT supported " +
"for a single function(8000) divided by 2.")
.intConf
.createWithDefault(2667)
Copy link
Member

@gatorsmile gatorsmile Aug 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also try 2731 and 2049? and see the perf difference?

8K = 8192 
8192 / 3 + 1 = 2731
8192 / 2 + 1 = 4097

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've already checked 2800; this value activated too-long-function optimization in Q17/Q66 and Q66 had regression. So, I think 2731 and 2049 possibly have the same regression (I've also checked 2900 that disabled this in Q17/Q66).

btw, why the computation is based on 8K? It seems the threshold of DontCompileHugeMethods is 8000?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

YES.... Just double check it. The default of HugeMethodLimitis 8000... Thanks!

.createWithDefault(4000)

val FILES_MAX_PARTITION_BYTES = buildConf("spark.sql.files.maxPartitionBytes")
.doc("The maximum number of bytes to pack into a single partition when reading files.")
Expand Down