[
https://issues.apache.org/jira/browse/CASSANDRA-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14587944#comment-14587944
]
Benedict commented on CASSANDRA-9499:
-------------------------------------
bq. So I'd personally prefer multiple (simple) encodings optimized to certain
assumption (obviously, within reason)
With multiple encodings, I think it will get confusing API-wise, however I
wasn't talking API, but implementation. It also incurs extra costs: the more
encoding paths we take, the worse our instruction cache population becomes.
Right now we are rarely IO constrained, but CPU constrained. I would much
rather see our encoding schemes be as efficient CPU-wise as they can be, and
lose the odd byte here or there.
I'm pretty sure we expect columns (in a row), and the number of partitions in a
result, to _typically_ be < 64, so the scheme I proposed would work just fine
for the typical case. The other two numbers are encoded once per large result,
so amortized cost is zero. As a result, it just shifts the "unlikeliness"
boundary for bumping up into 2 bytes, and I'm not sure we should agonise over
that.
> 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)
