[
https://issues.apache.org/jira/browse/HBASE-16278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391387#comment-15391387
]
Duo Zhang commented on HBASE-16278:
-----------------------------------
[~ikeda] One problem is that, we may use a byte[] as key multiple times in a
method, so declare a map with something like ByteArrayWrapper can prevent
allocating an extra object every time.
And I think it is also a burden that we need to track the interface change
between different java versions. For example, in java8 there is a
computeIfAbsent method, which is very useful. And master is claimed to only
support java 8+, so in master we should also implement this method. But for
branch-1, we can not implement it since we should also support java 7. Of
course, this is not a problem that can not be solved but I think a wrapper
class is simple and enough.
Thanks.
> Use ConcurrentHashMap instead of ConcurrentSkipListMap if possible
> ------------------------------------------------------------------
>
> Key: HBASE-16278
> URL: https://issues.apache.org/jira/browse/HBASE-16278
> Project: HBase
> Issue Type: Improvement
> Reporter: Duo Zhang
> Attachments: ConcurrentHashByteArrayMap.java
>
>
> SSD and 10G network make our system CPU bound again, so the speed of memory
> operation only code becomes more and more important.
> In HBase, if want to use byte[] as a map key, then we will always use CSLM
> even if we do not need the map to be ordered. I know that this could save one
> object allocation since we can not use byte[] directly as CHM's key. But we
> all know that CHM is faster than CSLM, so I wonder if it worth to use CSLM
> instead of CHM only because one extra object allocation.
> Then I wrote a simple jmh micro benchmark to test the performance of CHM and
> CSLM. The code could be found here
> https://github.com/Apache9/microbench
> It turns out that CHM is still much faster than CSLM with one extra object
> allocation.
> So I think we should always use CHM if we do not need the keys to be sorted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
