[ https://issues.apache.org/jira/browse/DRILL-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15265318#comment-15265318 ]
jean-claude edited comment on DRILL-4573 at 5/1/16 4:23 PM: ------------------------------------------------------------ I attached patch DRILL-4573-3 It fixes the issue reported DRILL-4645 The CharSequenceWrapper.toString() method was called. I decided to in-line the Matcher.replaceAll() to avoid creating that String altogether. Notice in the case there is nothing to replace I just re-use the input buffer. was (Author: jccote): I attached patch DRILL-4573-3 It fixes the issue reported DRILL-4645 The CharSequenceWrapper.toString() method was called. I decided to in-line the Matcher.replaceAll() to avoid creating that String altogether. Notice in the case there is nothing to replace I copy the input buffer into the output buffer. Can you confirm that is the best way to copy the input buffer into the output buffer? > 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)