[
https://issues.apache.org/jira/browse/CASSANDRA-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587771#comment-14587771
]
Benedict commented on CASSANDRA-9499:
-------------------------------------
There would be no overconsumption: we would _read_ more bytes that we needed,
but we would not move the buffer position until after. This method would work
for both the writer and the reader, and I don't see where the problems you
raise occur. The only ugliness would be, in the reader, _potentially_ extending
limit() (in the rare case we don't have any real bytes present) and resetting
it when done, but this would be a rare branch to take (although it could be
done unconditionally, since it's cheap), i.e. set {{limit(position + 8)}}
before; and set {{limit(previousLimit)}} after.
For the writer there is no such ugliness, so we should at least implement this
approach there: we build the long value we want, put it without moving the
position, and then shift the position forwards by only the populated length.
However, on the reader, since there _would_ be some ugliness, that may also
hinder the performance benefit (it would depend on the value being large,
whereas we probably expect it to be small, if we're using writevInt): we _know_
the value is at least two bytes long. So perhaps we should just call getShort()
before entering the loop, in the expectation/hope that we often won't require
the loop itself. We could even unroll the 6 iterations of the loop into a
switch statement with fall-through, since this should cap the branches at 1:
but it's probably not important to do so, given the method costs likely still
dominate.
We could, optionally, also have a fast route for when length == 8, since I
would expect that typically we willl vint encode either very small values, or
full long values.
> 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)
