[
https://issues.apache.org/jira/browse/DRILL-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15303306#comment-15303306
]
jean-claude commented on DRILL-4573:
------------------------------------
using the CharsetDecoder.decode method had the same performance as creating
full String objects. However my tests ran for a few minutes, it's possible it
would need to run longer to saturate the VM. But still it's nowhere near the
performance of just checking ASCII bytes.
I had thought of testing the buffer for ASCII only and then switching strategy.
So after seeing the results just mentioned I tried adding the test and switch
strategy approach. Instead of 25% faster I got 17%. So the test seem to add
about 7%. This is done over a text file containing UUID on each line.
I think using a test and switch strategy is potentially beneficial but I feel
it should have a configuration to turn on or off the additional check for ASCII
as it does incur a penalty when it turns out the buffer contained none ASCII
chars.
Just as a side note: I did consider performing the ASCII test as chars are
requested but the first thing the regex algo does is call the CharSequence for
the count of chars. So that's not a possible option.
Also while I'm at it. I do have another optimization idea for the LIKE
function. The SQL LIKE function is supposed to only support a % prefix or
suffix. And _ matching any character. The idea I have is to check if there's
any _ which is not very often used. Then using the same code used in the STRPOS
function to match a substring. This way the LIKE function can work by comparing
byte-to-byte and not making any copy.
> Zero copy LIKE, REGEXP_MATCHES, SUBSTR
> --------------------------------------
>
> Key: DRILL-4573
> URL: https://issues.apache.org/jira/browse/DRILL-4573
> Project: Apache Drill
> Issue Type: Improvement
> Reporter: jean-claude
> Priority: Minor
> Fix For: 1.7.0
>
> Attachments: DRILL-4573-3.patch.txt, DRILL-4573.patch.txt
>
>
> All the functions using the java.util.regex.Matcher are currently creating
> Java string objects to pass into the matcher.reset().
> However this creates unnecessary copy of the bytes and a Java string object.
> The matcher uses a CharSequence, so instead of making a copy we can create an
> adapter from the DrillBuffer to the CharSequence interface.
> Gains of 25% in execution speed are possible when going over VARCHAR of 36
> chars. The gain will be proportional to the size of the VARCHAR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
