[jira] Updated: (CASSANDRA-1788) reduce copies on read, write paths

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-1788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis updated CASSANDRA-1788:
--------------------------------------

    Attachment: 1788.txt

As planned, removes last copy on write and first on read.  Message.serializer calls are inlined and MessageSerializer is removed to avoid implying that it actually makes sense to call outside of sendOneWay / IncomingTcpConnection.

Bonus fix: removed copying DataOutputBuffer.asByteArray, replacing with wrap() of existing buffer with appropriate limit.

> reduce copies on read, write paths
> ----------------------------------
>
>                 Key: CASSANDRA-1788
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1788
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>             Fix For: 0.7.0
>
>         Attachments: 1788.txt
>
>
> Currently, we do _three_ unnecessary copies (that is, writing to the socket is necessary; any other copies made are overhead) for each message:
> - constructing the Message body byte[] (this is typically a call to a ICompactSerializer[2] serialize method, but sometimes we cheat e.g. in SchemaCheckVerbHandler's reply)
> - which is copied to a buffer containing the entire Message (i.e. including Header) when sendOneWay calls Message.serializer.serialize()
> - which is copied to a newly-allocated ByteBuffer when sendOneWay calls packIt
> - which is what we write to the socket
> For deserialize we perform a similar orgy of copies:
> - IncomingTcpConnection reads the Message length, allocates a byte[], and reads the serialized Message into it
> - ITcpC then calls Message.serializer().deserialize, which allocates a new byte[] for the body and copies that part
> - finally, the verbHandler (determined by the now-deserialized Message header) deserializes the actual object represented by the body
> Most of these are out of scope for 0.7 but I think we can at least elide the last copy on the write path and the first on the read.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.