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

Sahil Aggarwal commented on HBASE-20716:
----------------------------------------

Benchmark                                                       Mode      Cnt   
 Score  Error  Units

HbaseBytes.testToLongCheckAndDispatch     thrpt        6       352925235.054 ± 
7423950.697  ops/s

HbaseBytes.testToLongStaticInvoke                thrpt        6       
353652817.747 ± 6536569.256  ops/s

 

org.apache.hadoop.hbase.util.Bytes::toLongCheckAndDispatch (73 bytes)    - 
current impl

org.apache.hadoop.hbase.util.Bytes::toLong (33 bytes)   - impl using 
BEST_CONVERTER

Reduced the size of method by 40 bytes.

> Unsafe access cleanup
> ---------------------
>
>                 Key: HBASE-20716
>                 URL: https://issues.apache.org/jira/browse/HBASE-20716
>             Project: HBase
>          Issue Type: Improvement
>          Components: Performance
>            Reporter: stack
>            Assignee: Sahil Aggarwal
>            Priority: Critical
>              Labels: beginner
>         Attachments: HBASE-20716.master.001.patch, Screen Shot 2018-06-26 at 
> 11.37.49 AM.png
>
>
> We have two means of getting at unsafe; UnsafeAccess and then internal to the 
> Bytes class. They are effectively doing the same thing. We should have one 
> avenue to Unsafe only.
> Many of our paths to Unsafe via UnsafeAccess traverse flags to check if 
> access is available, if it is aligned and the order in which words are 
> written on the machine. Each check costs -- especially if done millions of 
> times a second -- and on occasion adds bloat in hot code paths. The unsafe 
> access inside Bytes checks on startup what the machine is capable off and 
> then does a static assign of the appropriate class-to-use from there on out. 
> UnsafeAccess does not do this running the checks everytime. Would be good to 
> have the Bytes behavior pervasive.
> The benefit of one access to Unsafe only is plain. The benefits we gain 
> removing checks will be harder to measure though should be plain when you 
> disassemble a hot-path; in a (very) rare case, the saved byte codes could be 
> the difference between inlining or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to