[
https://issues.apache.org/jira/browse/HBASE-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264434#comment-13264434
]
jirapos...@reviews.apache.org commented on HBASE-5625:
------------------------------------------------------
bq. On 2012-04-02 17:34:38, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/KeyValue.java, line 616
bq. > <https://reviews.apache.org/r/4607/diff/1/?file=97954#file97954line616>
bq. >
bq. > How do I know the buffer is big enough?
bq.
bq. Tudor Scurtu wrote:
bq. Added exception comment for when there is insufficient space remaining
in the buffer. Is that what you meant?
bq.
bq. Michael Stack wrote:
bq. I am not understanding how the allocation works. It seems arbitrary
unrelated to the actual result size that comes over from the server. Is that
so? If so, it seems unfriendly throwing an exception when allocated size and
what is returned from the server do not match.
bq.
bq. Tudor Scurtu wrote:
bq. Added check with reallocation in 'Result.binarySearch()'. For this I
had to add two methods in 'KeyValue' that calculate the number of bytes that
are taken up in a 'KeyValue' object's underlying buffer
('getKeyValueDataStructureSize()' and 'getKeyDataStructureSize()'). Is this ok,
and if so, how about replacing all manual calculations of these values in the
project with calls to the new methods?
I think I am beginning to understand what you are at (pardon me, I am a little
slow). You want to speed up finding KVs in big Results and part of the way in
which you do this is reuse of a buffer you keep private in Result. The buffer
will not match a specific KV.... usually it'll be too big and if it is too
small, you'll allocate a buffer big enough, a new one.
What locations would you put getKeyValueDataStructureSize into place? For
example?
- Michael
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4607/#review6623
-----------------------------------------------------------
On 2012-04-25 16:01:29, Tudor Scurtu wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/4607/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2012-04-25 16:01:29)
bq.
bq.
bq. Review request for hbase.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. 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.
bq.
bq. 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.
bq.
bq.
bq. This addresses bug HBASE-5625.
bq. https://issues.apache.org/jira/browse/HBASE-5625
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. src/main/java/org/apache/hadoop/hbase/KeyValue.java 9ae9e02
bq. src/main/java/org/apache/hadoop/hbase/client/Result.java df0b3ef
bq. src/test/java/org/apache/hadoop/hbase/TestKeyValue.java 786d2df
bq. src/test/java/org/apache/hadoop/hbase/client/TestResult.java f9e29c2
bq.
bq. Diff: https://reviews.apache.org/r/4607/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Added value check to TestResult#testBasic and TestResult.testMultiVersion.
bq.
bq.
bq. Thanks,
bq.
bq. Tudor
bq.
bq.
> 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
> Assignee: Tudor Scurtu
> Labels: patch
> Fix For: 0.96.0
>
> Attachments: 5625.txt, 5625v2.txt, 5625v3.txt, 5625v4.txt,
> 5625v5.txt, 5625v6.txt, 5625v7.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
