cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9499) Introduce writeVInt method to DataOutputStreamPlus
Date Tue, 16 Jun 2015 10:53:01 GMT

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

Benedict edited comment on CASSANDRA-9499 at 6/16/15 10:52 AM:
---------------------------------------------------------------

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 (a concrete
method in) {{AbstractDataInput}}, 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)


was (Author: benedict):
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)

Mime
View raw message