tustvold opened a new pull request, #4407:
URL: https://github.com/apache/arrow-rs/pull/4407
# Which issue does this PR close?
<!--
We generally require a GitHub issue to be filed for all bug fixes and
enhancements and this helps us generate change logs for our releases. You can
link an issue to this PR using the GitHub syntax. For example `Closes #123`
indicates that this PR will close issue #123.
-->
Relates to #3999
# Rationale for this change
<!--
Why are you proposing this change? If this is already explained clearly in
the issue then this section is not needed.
Explaining clearly why changes are proposed helps reviewers understand your
changes and offer better suggestions for fixes.
-->
As part of #3999 I'm trying to improve the consistency and correctness of
the arithmetic kernels, however, I am repeatedly bashing my head against the
dictionary support and therefore wanted to float this idea to see what people
think.
My major rationale is:
* Currently calling a kernel with a DictionaryArray and a scalar returns a
DictionaryArray, however, calling a kernel with two DictionaryArray returns a
PrimitiveArray, the latter feels strange to me
* Huge amount of code complexity, and code generation to support this
use-case
* Difficult to keep the arithmetic logic for PrimitiveArray values and
DictionaryArray values consistent
* We currently don't support operations between PrimitiveArray and
DictionaryArray, should we??
* The performance of operating directly on the dictionaries, vs casting
first, is broadly in the same ballpark of ~10s of ns per row
* I honestly don't really understand the use-case for a DictionaryArray of
primitives, they will be significantly slower to process than the corresponding
PrimitiveArray, orders of magnitude in some case, and will likely take up more
memory (especially given #3837 and similar)
I think what would help me be less frustrated bashing my head against this
would be some motivating use-case for this functionality, as far as I can tell
I can't see a compelling reason to ever use a DictionaryArray of primitives for
query computation, they're almost always just worse
Performance of arithmetic using this feature, vs just casting first, run
using (#4405)
```
dict_add(0) time: [354.31 µs 354.55 µs 354.84 µs]
change: [-1.1077% -0.7157% -0.2919%] (p = 0.00 <
0.05)
Change within noise threshold.
dict_add_checked(0) time: [31.384 µs 31.392 µs 31.401 µs]
change: [-1.3918% -0.7952% -0.4529%] (p = 0.00 <
0.05)
Change within noise threshold.
Found 4 outliers among 100 measurements (4.00%)
3 (3.00%) high mild
1 (1.00%) high severe
dict_add_cast(0) time: [44.593 µs 44.622 µs 44.657 µs]
change: [-3.3883% -3.3001% -3.2035%] (p = 0.00 <
0.05)
Performance has improved.
Found 4 outliers among 100 measurements (4.00%)
2 (2.00%) high mild
2 (2.00%) high severe
dict_add_cast_checked(0)
time: [44.130 µs 44.160 µs 44.192 µs]
change: [-1.6532% -1.2188% -0.8736%] (p = 0.00 <
0.05)
Change within noise threshold.
Found 4 outliers among 100 measurements (4.00%)
4 (4.00%) high mild
dict_add(0.1) time: [411.69 µs 411.94 µs 412.28 µs]
change: [-0.8818% -0.7008% -0.5335%] (p = 0.00 <
0.05)
Change within noise threshold.
Found 6 outliers among 100 measurements (6.00%)
5 (5.00%) high mild
1 (1.00%) high severe
dict_add_checked(0.1) time: [19.859 µs 19.872 µs 19.885 µs]
change: [+3.1645% +3.8146% +4.4437%] (p = 0.00 <
0.05)
Performance has regressed.
Found 13 outliers among 100 measurements (13.00%)
9 (9.00%) high mild
4 (4.00%) high severe
dict_add_cast(0.1) time: [67.510 µs 67.682 µs 67.866 µs]
change: [-32.706% -32.439% -32.166%] (p = 0.00 <
0.05)
Performance has improved.
Found 16 outliers among 100 measurements (16.00%)
3 (3.00%) low severe
9 (9.00%) low mild
2 (2.00%) high mild
2 (2.00%) high severe
dict_add_cast_checked(0.1)
time: [78.234 µs 78.265 µs 78.299 µs]
change: [-1.1505% -1.0897% -1.0254%] (p = 0.00 <
0.05)
Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
1 (1.00%) high mild
dict_add(0.5) time: [687.92 µs 688.56 µs 689.45 µs]
Found 4 outliers among 100 measurements (4.00%)
2 (2.00%) high mild
2 (2.00%) high severe
dict_add_checked(0.5) time: [72.906 µs 72.921 µs 72.939 µs]
Found 8 outliers among 100 measurements (8.00%)
7 (7.00%) high mild
1 (1.00%) high severe
dict_add_cast(0.5) time: [68.336 µs 68.367 µs 68.399 µs]
Found 6 outliers among 100 measurements (6.00%)
5 (5.00%) high mild
1 (1.00%) high severe
dict_add_cast_checked(0.5)
time: [126.81 µs 126.89 µs 126.97 µs]
Found 7 outliers among 100 measurements (7.00%)
6 (6.00%) high mild
1 (1.00%) high severe
dict_add(0.9) time: [498.11 µs 498.35 µs 498.60 µs]
Found 2 outliers among 100 measurements (2.00%)
1 (1.00%) high mild
1 (1.00%) high severe
dict_add_checked(0.9) time: [92.705 µs 95.673 µs 99.419 µs]
dict_add_cast(0.9) time: [69.080 µs 69.248 µs 69.383 µs]
dict_add_cast_checked(0.9)
time: [171.86 µs 171.97 µs 172.08 µs]
Found 3 outliers among 100 measurements (3.00%)
2 (2.00%) high mild
1 (1.00%) high severe
dict_add(1) time: [370.66 µs 370.83 µs 371.02 µs]
Found 21 outliers among 100 measurements (21.00%)
12 (12.00%) low severe
9 (9.00%) high mild
dict_add_checked(1) time: [31.390 µs 31.402 µs 31.414 µs]
Found 4 outliers among 100 measurements (4.00%)
3 (3.00%) high mild
1 (1.00%) high severe
dict_add_cast(1) time: [43.996 µs 44.022 µs 44.048 µs]
Found 1 outliers among 100 measurements (1.00%)
1 (1.00%) high severe
dict_add_cast_checked(1)
time: [45.406 µs 45.439 µs 45.476 µs]
Found 2 outliers among 100 measurements (2.00%)
2 (2.00%) high mild
```
# What changes are included in this PR?
<!--
There is no need to duplicate the description in the issue here but it is
sometimes worth providing a summary of the individual changes in this PR.
-->
# Are there any user-facing changes?
Yes, I suspect this will have downstream implications. Tagging @alamb
@viirya @wjones127 @jhorstmann
<!--
If there are user-facing changes then we may require documentation to be
updated before approving the PR.
-->
<!---
If there are any breaking changes to public APIs, please add the `breaking
change` label.
-->
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
