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

Benedict commented on CASSANDRA-6726:
-------------------------------------

Hmm. Looking at it a little more closely it appears we _do_ permit configurable 
chunk sizes for compressed files. I'd still be tempted to keep this simple with 
a ThreadLocal pool simple tracking the maximum size we've had to allocate, 
always allocating buffers of this size to the pool (unless full, in which case 
allocating exactly the requested size). Since in most cases the chunk size is 
unlikely to be configured, and certainly not to many different values, and 
they're only in use for the duration of a read, this should be more than 
sufficient. Neither is optimal in space utilisation, as the logarithmic pools 
have potentially O(NM) wasted space where N is the max allocated size and M is 
the number of buckets in use, whereas the max size pool wastes space 
proportional to T.(N-N' ) where N' is the minimum allocated size, and T the 
number of concurrently in use buffers.

Either one is going to be better than the current state of affairs.

> Recycle CompressedRandomAccessReader/RandomAccessReader buffers independently 
> of their owners, and move them off-heap when possible
> -----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6726
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6726
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Branimir Lambov
>            Priority: Minor
>              Labels: performance
>             Fix For: 3.0
>
>         Attachments: cassandra-6726.patch
>
>
> Whilst CRAR and RAR are pooled, we could and probably should pool the buffers 
> independently, so that they are not tied to a specific sstable. It may be 
> possible to move the RAR buffer off-heap, and the CRAR sometimes (e.g. Snappy 
> may possibly support off-heap buffers)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to