[
https://issues.apache.org/jira/browse/CASSANDRA-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12926413#action_12926413
]
Jonathan Ellis edited comment on CASSANDRA-1651 at 10/29/10 3:21 PM:
---------------------------------------------------------------------
bq. if a key/name was going to live in memory for a while, we would intern it
Is there a hole in this reasoning?
1. the only place we have these live in memory for a while is the key and row
caches; everything else only lasts for the duration of a read which is small
numbers of ms at most (i.e. less than the time between new or old gen GC runs)
2. if you are reading the same sequence multiple times without using key/row
cache then you are not configuring optimally so we can dismiss this scenario as
uninteresting
3. we have to read it (or wrap it) the sequence into a new buffer to do the
cache lookup; at this point the allocation has been done and replacing it with
an interned version doesn't matter since GCing now vs GCing when the read
finishes in a ms is going to be part of the same GC generation
was (Author: jbellis):
bq. if a key/name was going to live in memory for a while, we would intern
it
Is there a hole in this reasoning?
1. the only place we have these live in memory for a while is the key and row
caches; everything else only lasts for the duration of a read which is small
numbers of ms at most (i.e. less than the time between new or old gen GC runs)
2. if you are reading the same sequence multiple times then you should be
using a key/row cache; it is silly to discuss interning w/o this
3. we have to read it (or wrap it) the sequence into a new buffer to do the
cache lookup; at this point the allocation has been done and replacing it with
an interned version doesn't matter since GCing now vs GCing when the read
finishes in a ms is going to be part of the same GC generation
> Improve read performance by using byte array slabs
> --------------------------------------------------
>
> Key: CASSANDRA-1651
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1651
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: T Jake Luciani
> Assignee: T Jake Luciani
> Priority: Minor
> Fix For: 0.7.0
>
> Attachments: 1651_v1.txt
>
>
> Now that the code has switched to byte buffers internally, it should be
> possible to improve read performance by reducing the number of byte array
> allocations.
> This patch accomplishes this by and re-using sections of a larger byte array
> slab.
> I've benchmarked it locally and seen a slight improvement on reads, a larger
> scale benchmark should be performed.
> Also the size of a slab can be configured in cassandra.yaml
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
