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

Caleb Rackliffe commented on CASSANDRA-15393:
---------------------------------------------

bq. I'd done something sort of along these lines (albeit in the opposite 
direction) by adding the `ValueAware` class, so that AbstractType et al can 
operate directly on Cell objects without having to know what a cell is. 
Although I seem to default to keeping type information on the serializer / type 
side of things, there are benefits to each which we should discuss. And 
possibly a better name for ValueAware.

Unless we have a concrete plan for {{ValueAware}}, why don't we just remove it 
and use {{Cell}} directly? There might not be a real benefit to hiding the 
concept of a cell from the types and serializers. My comments here (ex. 
{{getLong()}}) are driving toward trying to eliminate as many places where we 
actually have to explicitly pair value and accessor as possible. 

> Add byte array backed cells
> ---------------------------
>
>                 Key: CASSANDRA-15393
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15393
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Local/Compaction
>            Reporter: Blake Eggleston
>            Assignee: Blake Eggleston
>            Priority: Normal
>             Fix For: 4.0-beta
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> We currently materialize all values as on heap byte buffers. Byte buffers 
> have a fairly high overhead given how frequently they’re used, and on the 
> compaction and local read path we don’t do anything that needs them. Use of 
> byte buffer methods only happens on the coordinator. Using cells that are 
> backed by byte arrays instead in these situations reduces compaction and read 
> garbage up to 22% in many cases.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to