-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize CompressedBigDecimal compareTo() #13086
Optimize CompressedBigDecimal compareTo() #13086
Conversation
ec29272
to
6333c05
Compare
} | ||
return this.toBigDecimal().compareTo(o.toBigDecimal()); | ||
|
||
int signum = signumInternal(result.length, result, (r, i) -> r[i]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure if i should create a concrete class or concrete impl of signumInternal for this case to avoid megamorphic callsite for the lambda passed in?
bc0f60a
to
f12dd1f
Compare
@@ -274,13 +276,74 @@ protected static <S> int signumInternal(int size, S rhs, ToIntBiFunction<S, Inte | |||
/* (non-Javadoc) | |||
* @see java.lang.Comparable#compareTo(java.lang.Object) | |||
*/ | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
accidental change? And I think the javadoc for this method is not helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea, i'm not sure what happened here. there are a lot of these javadoc comments from the original PR that was merged :/
i'll remove it
{ | ||
return compareTo(o, false); | ||
} | ||
public int compareTo(CompressedBigDecimal o, boolean expectOptimized) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I notice that this method is called by compareTo
method at line 283, and a false
is passed to this method as 2nd parameter. I don't find any other places that call this method with a true
value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's called in the unit test. It was a suggestion by @cheddar as a way to detect a regression in the optimized path of compareTo() in unit tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it's called by the UT only, usually we declare its visibility as package level, and use VisibileForTesting
annotation to make it more intuitive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh, he's not doing it that way because I hate the VisibleForTesting
annotation and adjusting the visibility only creates friction for the future without actually protecting anything. Those things combine to just pretend like the method is not part of the actual contract of the object when it is.
In this case, there is basically a "strict" version that expects that objects have already been aligned so that we can use a more optimal code path. But there's a more loose version as well that just "does the right thing". We have the tests that exercise this via queries only use the "strict" version because the normal query pipeline should be aligning things so that the more optimal code path is followed, but in production the non-strict version is actually used just in case. I.e. the tests are there to catch against regressions when running through queries, but there are other tests that also leverage the whole thing. In all, the "contract" of the object requires us to have both, otherwise we cannot test it. There also might be a case in production where we want to blow up if there is a mis-alignment, in that case, this method is a great way to achieve that.
f12dd1f
to
78bef43
Compare
I made an update so it can compare CBDs of different sizes and updated tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few questions, but overall approved.
...sed-bigdecimal/src/main/java/org/apache/druid/compressedbigdecimal/CompressedBigDecimal.java
Outdated
Show resolved
Hide resolved
...sed-bigdecimal/src/main/java/org/apache/druid/compressedbigdecimal/CompressedBigDecimal.java
Show resolved
Hide resolved
...sed-bigdecimal/src/main/java/org/apache/druid/compressedbigdecimal/CompressedBigDecimal.java
Outdated
Show resolved
Hide resolved
...sed-bigdecimal/src/main/java/org/apache/druid/compressedbigdecimal/CompressedBigDecimal.java
Outdated
Show resolved
Hide resolved
e3167b2
to
a8e1619
Compare
As titled, this optimizes the compareTo() function in CompressedBigDecimal. It directly compares the int[] rather than creating BigDecimal objects and using its compareTo. It handles unequal sized CBDs, but does require the scales to match.
a8e1619
to
ebc8090
Compare
Optimize CompressedBigDecimal compareTo()
As titled, this optimizes the compareTo() function in
CompressedBigDecimal. It does so in the case that the scale is
equal.
This PR has: