Improve url_decode performance for long strings - #7353
Conversation
|
Using the benchmark, here are the before and after performance numbers on a V100. The two numbers varying in the benchmark name are the number of rows and characters per row, respectively. After: |
davidwendt
left a comment
There was a problem hiding this comment.
This looks like a good solution. I don't think it is handling sliced columns correctly though.
vuule
left a comment
There was a problem hiding this comment.
Few minor comments. Will take another look once the sliced input tests are in place.
Codecov Report
@@ Coverage Diff @@
## branch-0.19 #7353 +/- ##
==============================================
Coverage ? 82.22%
==============================================
Files ? 100
Lines ? 16969
Branches ? 0
==============================================
Hits ? 13953
Misses ? 3016
Partials ? 0 Continue to review full report at Codecov.
|
|
Thanks a ton for the quick reviews! I have yet to address the excellent feedback, but I wanted to post a slightly modified version of the algorithm that I found was significantly faster in practice to see if there was any suggestions/feedback on the approach. Rather than perform the expensive binary search from each character index three times (during This bears out in the new performance numbers. I added a 50% chance version of an escape sequence to compare as the number of escape sequences becomes significantly more common. |
vuule
left a comment
There was a problem hiding this comment.
looks great. Just a couple of very minor comments.
|
@gpucibot merge |
Fixes #7348.
This changes the
url_decodealgorithm from row-level parallelism to character-level parallelism which improves the performance when operating on string columns that have longer average string lengths. A benchmark forurl_decodehas also been added.