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

atppp commented on HBASE-1347:
------------------------------

All ran faster in my old test, however, that was not a good test. 

I did a better test today: run just

byte[] HRegion.binaryIncrement(byte[], long amount)

100M times (converting long to and from byte[] is done outside the loop, so 
improvement in Bytes class won't affect old algorithm's performance.). Here's 
result:

current code on 0.19 branch: (time per run)
amount=+1: 10.9 ns
amount=+1000: 23.3 ns
amount=-1: 98.7 ns (result incorrect)
amount=random Long: ~100 ns (result is incorrect when amount<0)

Performance of my quick fix is pretty consistent (obviously):
with 0.19 branch Bytes class: ~73 ns
with trunk branch Bytes class: ~53 ns

I imagine most people do amount=+1, so the difference is huge. I don't want to 
propose my quick fix code as a "good" solution, but I am uploading that patch 
anyway for reference.





> HTable.incrementColumnValue does not take negative 'amount'
> -----------------------------------------------------------
>
>                 Key: HBASE-1347
>                 URL: https://issues.apache.org/jira/browse/HBASE-1347
>             Project: Hadoop HBase
>          Issue Type: Improvement
>          Components: client
>    Affects Versions: 0.19.1
>         Environment: Ubuntu 8.10
>            Reporter: atppp
>            Priority: Minor
>             Fix For: 0.19.2
>
>
> Apparently HRegion.binaryIncrement() assumes argument 'amount' is always 
> positive. It would be nice to support decrement operation. In my application, 
> a counter can go both up and down.
> Quick fix is
>   public byte [] binaryIncrement(byte [] value, long amount) {
>     return Bytes.toBytes(Bytes.toLong(value) + amount);
>   } 
> but it is 2x~3x slower than current implementation for small positive 
> 'amount' value. I have not yet found a good implementation to support 
> negative 'amount' argument, AND match the speed of current implementation. 
> Anyway, I just want to throw this out there and see if anybody is interested 
> in negative 'amount' support. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to