cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9797) Don't wrap byte arrays in SequentialWriter
Date Thu, 16 Jul 2015 15:53:04 GMT


Sylvain Lebresne commented on CASSANDRA-9797:

bq. I think perhaps the correct thing to do is partially revert CASSANDRA-8709

I'm not familiar with that patch in the first place so no particular opinion on that a priori.
That said, from a quick glance it looks like the attached patch does fix {{writeBytes}} and
{{writeUTF}} and the patch is simple enough that it's maybe simpler than reverting parts of
CASSANDRA-8709 (until CASSANDRA-9500 lands that is)? Unless you have worries about the patch
of course.

> Don't wrap byte arrays in SequentialWriter
> ------------------------------------------
>                 Key: CASSANDRA-9797
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>              Labels: performance
>             Fix For: 3.x
>         Attachments: 9797.txt
> While profiling a simple stress write run ({{cassandra-stress write n=2000000 -rate threads=50}}
to be precise) with Mission Control, I noticed that a non trivial amount of heap pressure
was due to the {{ByteBuffer.wrap()}} call in {{SequentialWriter.write(byte[])}}. Basically,
when writing a byte array, we wrap it in a ByteBuffer to reuse the {{SequentialWriter.write(ByteBuffer)}}
method. One could have hoped this wrapping would be stack allocated, but if Mission Control
isn't lying (and I was told it's fairly honest on that front), it's not. And we do use that
{{write(byte[])}} method quite a bit, especially with the new vint encodings since they use
a {{byte[]}} thread local buffer and call that method.
> Anyway, it sounds very simple to me to have a more direct {{write(byte[])}} method, so
attaching a patch to do that. A very quick local benchmark seems to show a little bit less
allocation and a slight edge for the branch with this patch (on top of CASSANDRA-9705 I must
add), but that local bench was far from scientific so happy if someone that knows how to use
our perf service want to give that patch a shot.

This message was sent by Atlassian JIRA

View raw message