[ 
https://issues.apache.org/jira/browse/CASSANDRA-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587843#comment-14587843
 ] 

Benedict commented on CASSANDRA-9499:
-------------------------------------

bq. which means we still can change the encoding as it pleases us

Perhaps we should then. That way the size indicator can be determined as (-120 
- value), with the negative values giving [-6..0] and positive [0..6]. Then the 
{{vIntDecoding.vIntIsNegative}} method can vanish, and we can just use the 
signbit of the size, and can truncate the signbit for iteration.

bq. Maybe it could also make sense to have an "unsigned" variant for when we 
know the value written is positive.

Could you give an example of where this would be helpful? I'm guessing we'll be 
using this in places where we have either an int or long, in which case it will 
be decoded into something that is signed, and I can't see us using a long 
instead of an int, just for the extra bit (we may as well just use the whole 
long, if we're vint encoding it)?

bq. And as a nit, I think it would be convenient in practice to have methods 
for int 

Agreed. We can simply provide default methods in the DataOutputStreamPlus and 
DataInputPlus, that just wrap the casts/calls to the long variants. If there 
are no other implementations, it's quite likely they will get inlined  
(although I don't have time to hunt through hotspot to confirm if inlining 
decisions occur before or after the vtable resolution of default methods, I 
hope they did it in a way that supported it)

> Introduce writeVInt method to DataOutputStreamPlus
> --------------------------------------------------
>
>                 Key: CASSANDRA-9499
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9499
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Ariel Weisberg
>            Priority: Minor
>             Fix For: 3.0 beta 1
>
>
> CASSANDRA-8099 really could do with a writeVInt method, for both fixing 
> CASSANDRA-9498 but also efficiently encoding timestamp/deletion deltas. It 
> should be possible to make an especially efficient implementation against 
> BufferedDataOutputStreamPlus.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to