[
https://issues.apache.org/jira/browse/CASSANDRA-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14589904#comment-14589904
]
Ariel Weisberg commented on CASSANDRA-9499:
-------------------------------------------
Doesn't shifting the continuation bits to the first byte penalize the range of
1-byte values? Supposedly that is the most common and so having 1 or 2 byte
values with as much range as possible is a big advantage. Comments in the
Google code make it seem like it's all about 1-byte values and that is the
thing to optimize for.
In practice if you only have to process one or two bytes the current
implementation won't have to loop that many times.
I don't understand how you can use a variable number of top order bits in the
first bytes to indicate the number of bytes. How can you tell the difference
between length bytes and value bytes? The way the existing code that doesn't
use length extension works (and is simple) is that it drops the remaining bits
of the first byte. That is something we want to get away from I thought.
> 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)
