cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9499) Introduce writeVInt method to DataOutputStreamPlus
Date Tue, 16 Jun 2015 12:23:00 GMT


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:
>             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

View raw message