cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6697) Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible
Date Thu, 13 Feb 2014 09:59:20 GMT

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

Benedict commented on CASSANDRA-6697:
-------------------------------------

I agree this is far from the ideal situation, however I want to be certain at least that we
*can* make this optimisation in a way we're happy with before moving us to off-heap Cell implementations,
whether or not we apply it immediately. Without something like this, especially with compound
primary keys, we could see dramatic increases in garbage production. Note that any name or
CQL row lookup within a row will need 3.lg N bytebuffer constructions just to locate it. If
we're looking up multiple names, this could rapidly get very problematic. Note that I don't
expect throughput to *necessarily* be improved with this, but garbage is our number one enemy
for latency, and latency spikes are one of our user's biggest headaches.

Whilst this isn't ideal, I'm actually much happier with the result than I expected to be.
It's pretty neat and tidy, and not *so* brittle - if ever in doubt just use referrable(),
which is essentially our current semantics. I'm might be with you at least on mitigating it
by defensively using it in places where there's any ambiguity (or potential for future ambiguity).

There is one other approach to this, which is to pair this up more closely with the off-heap-memtable
code, and maintain a per-thread free-list of bytebuffers that is automatically managed with
the RefAction stuff introduced in CASSANDRA-6689. This might be slightly safer, although I'm
not so fond of it. Harder to do micro-optimisations, and probably slightly increased overhead.
Although a benefit is zero extra cost for on-heap.

What I had hoped to use was escape analysis. But that won't be good enough for a long time,
and even when it is, it almost certainly won't work with unsafe, which means we would have
to move off of ByteBuffer, which may be infeasible. So it may never help us.

Note after three failed attempts yesterday to edit the title, the correct dependent issue
is CASSANDRA-6694. 

> Refactor Cell and CellName ByteBuffer accessors to avoid garbage allocation where possible
> ------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-6697
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6697
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>             Fix For: 2.1
>
>
> This is a prerequisite for CASSANDRA-6689.
> The basic idea is to, if unsafe is available, abuse it to modify preallocated ByteBuffers
so that when they are short lived they do not need to be instantiated. Initially this will
only be helpful for comparisons and lookups on the BBs, but with some modifications to the
read path we should be able to reduce the need in CASSANDRA-6689 to construct BBs to pass
to the native protocol (thrift may have to continue as is)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message