hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiroshi Ikeda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16278) Use ConcurrentHashMap instead of ConcurrentSkipListMap if possible
Date Mon, 25 Jul 2016 07:43:21 GMT

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

Hiroshi Ikeda commented on HBASE-16278:

Creating an object itself are quite light-weight and that has the almost same cost as synchronization
without contention, according to my old Java book. If you haven't worry about how many times
we access volatile fields nor CAS, it would not make sense to just think about creating small
objects (and concurrent maps will use CAS many times in order to avoid block).

However, I agree that using raw byte arrays is a bad design because of their mutability, in
general. But it seems too late (and we cannot help from the beginning since Hadoop have adopted
that in its API) and there too many usages of raw bytes. From viewpoints of both performance
and object-oriented programing, I think it would not pay to do something about that.

I didn't know the master just supports Java8+, but I think a developer who want to use the
new method can fix the code. After all, maps using mutable keys cannot be used for general

> 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

View raw message