[
https://issues.apache.org/jira/browse/DRILL-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300832#comment-15300832
]
jean-claude commented on DRILL-4573:
------------------------------------
I have a solution. But I did not get a chance to finish it. The problem right
now is that there has to be a mapping between the UTF-8 encoded data and the
sequence of chars.
{code}
private CharBuffer charBuffer = CharBuffer.allocate(1024*16);
private CharsetDecoder decoder = Charset.forName("UTF-8").newDecoder();
public void setBuffer(int start, int end, DrillBuf buffer) {
ByteBuffer byteBuf = buffer.nioBuffer(start, end-start);
boolean endOfInput = true;
decoder.reset();
CoderResult result = decoder.decode(byteBuf, charBuffer, endOfInput);
if(result.isOverflow()){
// Not enough space in the charBuffer.
}
this.start = 0;
this.end = charBuffer.position();
if(result.isError()){
try {
result.throwException();
} catch (CharacterCodingException e) {
throw new RuntimeException(e);
}
}
}
{code}
This would have the benefit of using the same conversion code used by the Java
String but without re-allocating char arrays and String objects for every test.
The CharBuffer can be re-used and grown if needed. It's not zero-copy but I
believe it would help nonetheless.
What remains is growing the CharBuffer when needed, testing performance.
> 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)
