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

[email protected] commented on HBASE-5625:
------------------------------------------------------



bq.  On 2012-04-28 23:39:41, Michael Stack wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/KeyValue.java, line 181
bq.  > <https://reviews.apache.org/r/4607/diff/3/?file=104237#file104237line181>
bq.  >
bq.  >     So you have plans to use these elsewhere in the codebase?  If so, 
its ok that they are public.

Replaced manual calculations of infrastructure sizes with calls to the new 
methods in 'KeyValue'.


bq.  On 2012-04-28 23:39:41, Michael Stack wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/KeyValue.java, line 542
bq.  > <https://reviews.apache.org/r/4607/diff/3/?file=104237#file104237line542>
bq.  >
bq.  >     This could be 'as its backing data buffer'?  If so, I can address 
that on commit

Fixed.


bq.  On 2012-04-28 23:39:41, Michael Stack wrote:
bq.  > src/main/java/org/apache/hadoop/hbase/client/Result.java, line 256
bq.  > <https://reviews.apache.org/r/4607/diff/3/?file=104238#file104238line256>
bq.  >
bq.  >     Here you are trying to make a smart guess on a buffer size that will 
serve for multiple invocations on binarySearch?  Your hope is that you'll not 
have to reallocate the buffer the next time you come through here because the 
buffer should have enough space in it to hold the next random KV that comes 
through here?

Exactly. The power of 2 implementation could have grown too rapidly, so I 
modified it to pad to a size equal to the smallest multiple of a configurable 
constant.


- Tudor


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4607/#review7365
-----------------------------------------------------------


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, 5625v8.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

        

Reply via email to