Expensive calls to BigDecimal.equals

[phdoerfler]

Grackle seems to call BigDecimal.equals a lot. In my case, these take 50% of the thread's time which processes the query (490 of 1091 samples) (see highlighted region):

One of, if not the main culprit, seems to be assert(leafFocus != FailedJoin) in SqlMapping.
Replacing the equals with eq and thus referential equality (which should be safe here since FailedJoin is a singleton) there and in a few other related areas gets rid of the costly BigDecimals.equals completely, avoiding the expensive stack trace creation.

[phdoerfler]

This profiling result is from a rather large query touching 60k rows in postgres. To better expose the effects of this change, I instrumented grackle where each phase gets measured separately. For this particular case, the proposed optimization cuts the time spent in the "assemble" [1] phase in half:

┌─────────────────┬───────────────────────┬────────────────────────────────────────┐
│                 │        before         │                 after                  │
├─────────────────┼───────────────────────┼────────────────────────────────────────┤
│ assemble mean   │ 911.5ms               │ 476.1ms                                │
├─────────────────┼───────────────────────┼────────────────────────────────────────┤
│ assemble median │ 907.8ms               │ 437.9ms                                │
├─────────────────┼───────────────────────┼────────────────────────────────────────┤
│ assemble range  │ 888.8–953.6ms (tight) │ 423–470ms (18/20), 2 GC-pause outliers │
└─────────────────┴───────────────────────┴────────────────────────────────────────┘

I've done 25 runs each. Here's detailed numbers from every 5th run:

before (phase-timing-before, expensive .equals)
run    parse  elaborate  sql-plan     jdbc   assemble  complete
5      1.014      3.804     3.436  333.961    909.561     0.014
10     0.643      2.272     2.728  302.946    914.447     0.006
15     0.711      1.775     2.429  287.934    910.770     0.007
20     0.608      1.576     2.174  328.518    921.302     0.007
25     0.401      1.393     1.347  311.607    937.957     0.007

after (topic/sql-benchmarks HEAD, eq-based)
run    parse  elaborate  sql-plan     jdbc   assemble  complete
5      1.173      3.556     4.450  349.664   1059.676     0.008
10     1.258      2.657     3.053  296.040    425.023     0.034
15     0.976      2.121     2.679  281.925    435.149     0.007
20     0.909      1.923     2.043  314.339    442.736     0.008
25     0.631      1.719     2.559  285.398    427.654     0.006

This was a sneaky one because the expensive call to BigDecimal.equals was hiding in:

• row(c) != FailedJoin,
• assert(leafFocus != FailedJoin), and
• case FailedJoin => / case None => in a pattern match

which all desugar to a call to .equals on the left-hand value. Some of these left-hand values happen to be scala.math.BigDecimal in my particular case (thanks to a "money" column in my test data set). Those resulted in calling BigDecimal.equals(FailedJoin) or BigDecimal.equals(None). This by itself would be totally fine, of course. However, BigDecimal.equals throws+catches an ArithmeticException internally (via isValidLong) whenever the other side isn't itself a BigDecimal, making it very expensive. Nothing in the code in this spot mentions BigDecimal at all, which is why it's easy to miss.

[1] assemble phase = QueryInterpreter.runValue (called from runRootValue), modules/core/src/main/scala/queryinterpreter.scala:179. Where the flat SQL result is "un-flattened" back into an object structure matching the query. The recursive tree walking is what triggers the expensive equals so often that it causes a slowdown.