Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Improve performance of casting
DictionaryArray
toStringViewArray
#5871Improve performance of casting
DictionaryArray
toStringViewArray
#5871Changes from 1 commit
63db275
0308dd4
c27d548
fdebc0e
ca11706
52c28c1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 think calling
nulls()
doesn't handle the case where the dictionary value itself (rather than the key) was nullarrow-rs/arrow-array/src/array/dictionary_array.rs
Line 727 in cf59b6c
I think this should call
logical_nulls()
instead:arrow-rs/arrow-array/src/array/dictionary_array.rs
Line 731 in cf59b6c
Also, it would be good to create a test case that covers this too
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.
Nice catch! added a new test to cover this
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.
(fyi there seem to be no new commits to this PR)
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.
added now!
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.
Another potential optimization is a separate loop if there are no nulls in keys (so we can avoid the branch)
Another potental idea is to use
value_offsets.windows(2)
as an iterator to avoid the bounds checks invalue_offsets
However, I think we should merge this basic PR in as is, and then add a bencmark and optimize this kenrnel as a follow on PR (if we care). I can file a ticket if @tustvold agrees
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.
ops, I checked in a
append_view_unchecked
.But if we do
try_append_view
, it is even slower than theunpack_dictionary
approachThere 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 can also move
append_view_unchecked
as a follow-up PR and potentially clean up other use cases where ByteViews are manually constructed.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.
Instead of creating the views directly, what do you think about using
try_append_view
andtry_append_block
added in this PR: #5796Maybe as bonus points you could add a benchmark for this casting operation, and see if adding
append_view_unchecked
would make any differenceThere 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.
Unfortunately, adding
append_view_unchecked
improved the performance by 50%I think it justifies adding
append_view_unchecked
, what do you think?Also, should I add the benchmark to the repo? It's a bit tricky to setup two versions of the cast implementation..
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.
Makes sense to me
I do think we should add the benchmark to the repo (so we can use it for future optimizations)
In terms of justifying
append_view_unsafe
I think running the benchmark on a local checkout that callsappend_view
and then revert and run the same benchmark is fine (which is presumably what you did)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.
Can you please update this test to have a dictionary array that has:
Perhaps what you can do is create a
StringArray
fromVIEW_TEST_DATA
and then make create the indexes manuallyLike this example https://docs.rs/arrow/latest/arrow/array/struct.DictionaryArray.html#example-from-existing-arrays
Does that make sense?