Uh oh!
There was an error while loading. Please reload this page.
[SPARK-26978][CORE][SQL] Avoid magic time constants - #23878
Conversation
srowen
left a comment
There was a problem hiding this comment.
Good change, just a few comments
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
SparkQA
commented
Feb 23, 2019
Test build #102708 has finished for PR 23878 at commit
|
SparkQA
commented
Feb 23, 2019
Test build #102710 has finished for PR 23878 at commit
|
srowen
left a comment
There was a problem hiding this comment.
Looks good; you can remove benchmark
SparkQA
commented
Feb 24, 2019
Test build #102722 has finished for PR 23878 at commit
|
felixcheung
left a comment
There was a problem hiding this comment.
probably should add [SQL] in the PR title?
SparkQA
commented
Feb 25, 2019
Test build #102725 has finished for PR 23878 at commit
|
SparkQA
commented
Feb 25, 2019
Test build #102726 has finished for PR 23878 at commit
|
The PR touches not only |
MaxGekk
commented
Feb 25, 2019
@felixcheung added |
| (c, evPrim, evNull) => | ||
| code"""$evPrim = | ||
| org.apache.spark.sql.catalyst.util.DateTimeUtils.millisToDays($c / 1000L, $tz);""" | ||
| org.apache.spark.sql.catalyst.util.DateTimeUtils.millisToDays( |
There was a problem hiding this comment.
I have a little bit concern to use a method call in the generated code. This change includes # of Java bytecode to be generated while the original code uses / for long type.
Do we take the readability and maintanance or smaller generated bytecode?
There was a problem hiding this comment.
The call toMillis() should be inlined, shouldn't it?
There was a problem hiding this comment.
I agree with you @kiszk; this probably only adds a few ops though to invoke a static method vs a division. The issue here is the size of the generated bytecode, so the implementation of toMillis doesn't matter nor whether it's JITted at runtime.
There was a problem hiding this comment.
Should I revert all changes in code blocks?
There was a problem hiding this comment.
I reverted it back to division.
Uh oh!
There was an error while loading. Please reload this page.
SparkQA
commented
Feb 26, 2019
Test build #102765 has finished for PR 23878 at commit
|
srowen
commented
Feb 26, 2019
Merged to master |
…le expressions ## What changes were proposed in this pull request? Reverted initialization of date-time constants in `DateTimeUtils` introduced by apache#23878. As a comment in [Delta repo](https://github.com/delta-io/delta) states, the compiler can do additional optimizations if values can be calculated at compile time: https://github.com/delta-io/delta/blob/master/src/main/scala/org/apache/spark/sql/delta/util/DateTimeUtils.scala#L63-L75 ## How was this patch tested? This was tested by existing test suites. Closesapache#25116 from MaxGekk/datetime-consts-init. Authored-by: Maxim Gekk <maxim.gekk@databricks.com> Signed-off-by: herman <herman@databricks.com>
What changes were proposed in this pull request?
In the PR, I propose to refactor existing code related to date/time conversions, and replace constants like
1000and1000000byDateTimeUtilsconstants and transformation functions fromjava.util.concurrent.TimeUnit._.How was this patch tested?
The changes are tested by existing test suites.