-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-27839][SQL] Change UTF8String.replace() to operate on UTF8 bytes #24707
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
Closed
Closed
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
f3082d3
Optimize UTF8String.replace() / StringReplace expression.
JoshRosen b06d917
Can't interpolate as literals due to Scala string escaping issue.
JoshRosen b51035b
Correct referenceObj variable naming typo
JoshRosen 6fd7714
Implement direct replace() over UTF8String bytes.
JoshRosen ec423f1
Roll back codegen changes.
JoshRosen 5c74048
Merge remote-tracking branch 'origin/master' into faster-string-replace
JoshRosen 8123e42
Fix comment typo
JoshRosen 6188dcd
Remove ternary operator
JoshRosen File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
One consideration here: do we need to make a defensive copy? If so, we can't do this optimization.
Why might we need to copy a
UTF8String? TheUTF8Stringinstance itself is effectively immutable, but the underlying storage might be a region of potentially-not-exclusively-owned memory (either direct/off-heap memory or a region of along[]array), so we might need to perform a copy in case we're going to buffer / otherwise hold onto theUTF8Stringpast a point where the underlying underlying storage memory could be mutated.I think the most common case to worry about would be a UTF8String which is backed by memory that is part of a larger
UnsafeRow. If we're doing row-at-a-time processing and aren't holding onto thisUTF8Stringacross rows then I think we're ok since changes to rows' memory during single-row processing would impact many parts of Spark and would probably be detected. In the few places where we do hold references across evaluations / rows then we need to copy, but I suspect most places already do this: for example, see theregexp.clone()in theRegExpReplaceexpression.My intuition is that we probably don't need to make a defensive copy here because I doubt we have parts of the code which specifically assume that
replace()will copy (i.e. which are abusingreplace()as a slowclone()mechanism). Put differently, I suspect that any code which would fail due to lack of copying inreplace()is also vulnerable to this problem from other sources (including simply reading a string from a row without further modification), so I don't think we need to add extra copying here.I'd love to get additional sets of eyes on this, though, and I'd ultimately be ok with changing
return thistoreturn this.clone()(and updating the otherreturn thisuses inUTF8String) if we conclude that this isn't safe (or are uncertain and want to err on the side of caution).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 your intuition is right here.