[
https://issues.apache.org/jira/browse/HBASE-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680589#action_12680589
]
Jonathan Gray commented on HBASE-1252:
--------------------------------------
Benchmarking results:
{code}
incrementAsLong : Incremented 100000 times by 1 in 99 ms (current value is
100000)
incrementAsBytes : Incremened 100000 times by 1 in 9 ms (current value is
200000)
incrementAsLong : Incremented 100000 times by 100 in 100 ms (current value is
10000000)
incrementAsBytes : Incremened 100000 times by 100 in 46 ms (current value is
20000000)
{code}
When the number gets over 500 or so, the byte increment gets slower. Going to
work on an optimization to try and make them at least approx the same for high
incrementing values.
> Make atomic increment perform a binary increment
> ------------------------------------------------
>
> Key: HBASE-1252
> URL: https://issues.apache.org/jira/browse/HBASE-1252
> Project: Hadoop HBase
> Issue Type: Improvement
> Affects Versions: 0.19.0
> Reporter: Jonathan Gray
> Assignee: Jonathan Gray
> Priority: Minor
> Fix For: 0.19.1, 0.20.0
>
>
> A few issues related to recently committed HBASE-803
> - The HTable api still takes an integer amount rather than long, mismatching
> HRI.
> - Binary increments are 10 times faster for small amounts than going
> Bytes.toLong, += amount, Bytes.toBytes. Twice as fast for large amounts
> (binary incrementor just loops a bunch of single increments, though there is
> plenty of room for optimizations in my current implementation)
> - Using a binary increment means we don't have to worry about the size of the
> value. If someone wants a 16 byte value they can have it, just have to
> initialize as such. If no existing value exists, will default to long/8
> bytes. Only odd behavior will be what happens when you are at the max value,
> currently will just stay at all 11111 binary. Could actually grow the byte[]
> but then we can't do things in place. I'm okay with leaving it like that, not
> exactly sure what the current implementation would do, throw an exception or
> wrap?
> - Using binary incrementing, we can directly manipulate values in the
> memcache rather than sending updates with the same timestamp. I think we
> should hold off on doing this until HBASE-1234 goes in. We'll then have to
> deal directly with hlog. (this issue is not going to address this)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
