cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-1788) reduce copies on read, write paths
Date Thu, 09 Dec 2010 20:08:02 GMT


Jonathan Ellis commented on CASSANDRA-1788:

Rebooted v4 by first adding MessageSerializerTest with a bytesToHex string of the old-style
bytes-on-wire to make sure I'm not breaking it.  Then when I add the new code I'm testing
that new code can read old bytes, as well as old code reading new bytes.  Everything comes
up clean.  I think I need another set of eyes on this.

(01 is large because I encapculated MS.instance in a getter to break an initialization-cycle

> reduce copies on read, write paths
> ----------------------------------
>                 Key: CASSANDRA-1788
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>             Fix For: 0.7.1
>         Attachments: 0001-setup.txt, 0002-remove-copies-from-network-path.txt, 1788-v2.txt,
1788-v3.txt, 1788-v4.txt, 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.

View raw message