[
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)
