hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5625) Avoid byte buffer allocations when reading a value from a Result object
Date Fri, 23 Mar 2012 21:13:28 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237134#comment-13237134

stack commented on HBASE-5625:

How do I know the provided buffer big enough?

+  public KeyValue(byte [] buffer,

What can we do to ensure that the checks in createByteArray and writeByteArray, your new method,
are shared rather than duplicated?

Put all of the below on one line or add curlies:

+    if (!Bytes.equals(family, foffset, flength, this.bytes, o, fl))
+      return false;

Ditto for other similar formattings

Do we need both containsNonEmptyColumn and containsEmptyColumn?

Should loadValue be in KeyValue?

I like createFirstOnRow as method name instead of getSearchTerm.  The former describes what
is happening?

We should use your new binarySearch instead of what we have now?

Thanks for looking into this stuff.

What made you start digging here?   You have big Result objects with lots of kvs?
> Avoid byte buffer allocations when reading a value from a Result object
> -----------------------------------------------------------------------
>                 Key: HBASE-5625
>                 URL: https://issues.apache.org/jira/browse/HBASE-5625
>             Project: HBase
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 0.92.1
>            Reporter: Tudor Scurtu
>              Labels: patch
>         Attachments: 5625.txt, 5625v2.txt
> When calling Result.getValue(), an extra dummy KeyValue and its associated underlying
byte array are allocated, as well as a persistent buffer that will contain the returned value.
> These can be avoided by reusing a static array for the dummy object and by passing a
ByteBuffer object as a value destination buffer to the read method.
> The current functionality is maintained, and we have added a separate method call stack
that employs the described changes. I will provide more details with the patch.
> Running tests with a profiler, the reduction of read time seems to be of up to 40%.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message