[
https://issues.apache.org/jira/browse/CASSANDRA-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-1714:
--------------------------------------
Attachment: zerocopy.txt
patch implements the main zero-copy method (FileDataInput.readBytes) but there
are details left to solve:
1. LazilyCompactedRowTest deals with inputstreams which conflicts w/ our need
to deal w/ FDI. I refactored out AbstractDataInput so we could implement a
ByteBufferFileDataInput relatively easily but maybe changing the test is better.
2. We make a ton of calls to ByteBuffer.array() which is invalid with a direct
buffer. I started cleaning these up but there are more left. (Some calls may
be okay if we know the BB involved is always allocated on the heap; relying on
the test suite may be less work than changing *every* array() call.)
3. AFAIK the only performant way to write the contents of a direct buffer is
with FileChannel, which conflicts with our ICompactSerializer[2] code that
deals with DataInput[Stream]. Only the Column stuff cares deeply about this I
think (since nothing else deals w/ direct buffers) but if we start using a
FileChannel for our sockets then that probably forces a cascading change
everywhere else.
> zero-copy reads
> ---------------
>
> Key: CASSANDRA-1714
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1714
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Fix For: 0.7.1
>
> Attachments: zerocopy.txt
>
>
> Since we are already using mmap'd ByteBuffers in MappedFileDataInput we
> should be able to do zero-copy reads (via buffer.slice()), which would give
> us better performance than CASSANDRA-1651 without having to worry about
> buffer management.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
