[
https://issues.apache.org/jira/browse/HBASE-20716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524617#comment-16524617
]
stack commented on HBASE-20716:
-------------------------------
Thanks [~awked06] Helps.
So perf diff is near zero (when c2/level 4 optimized/inlined) but size diff is
substantial.
Both methods will be inlined because under the default small method size (31
IIRC)
More interesting is the approach to the big method limit of 2000 bytes. Say one
of our hot cell compares that does get of row, column, qualifier, timestamp,
sequenceid, lengths (short/int/byte), etc. checking for UNSAFE_UNALIGNED,
ENDIANNESS, and whether UNSAFE is available or not could be 5 or 10 checks of
various booleans; it could be 100 or 200 bytes that we might be able to do
without (Could do actual count in jitwatch if were important). Would be crazy
if these checks were diff between inlining or not.
Generally the JIT does a good job figuring it out but I was in here recently
and noticed that small improvements in our hot cell compare -- static vs
dynamic dispatch, inlined vs non-inlined, etc. -- can manifest as improvements
in overall macro throughput so I'm a little, ahem, 'sensitive' around these
parts.
Thanks.
> Unsafe access cleanup
> ---------------------
>
> Key: HBASE-20716
> URL: https://issues.apache.org/jira/browse/HBASE-20716
> Project: HBase
> Issue Type: Improvement
> Components: Performance
> Reporter: stack
> Priority: Critical
> Labels: beginner
> Attachments: 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)
