[
https://issues.apache.org/jira/browse/CASSANDRA-8630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14531575#comment-14531575
]
Ariel Weisberg commented on CASSANDRA-8630:
-------------------------------------------
This kind of similar to the work done for CASSANDRA-8670. We never extended it
to RandomAccessReader because it is not a straightforward but it should be
doable. The theory behind this is solid and we should try and capture the value.
Things have changed a bit in the code this patch is based on.
RandomAccessReader extends AbstractDataInput now so I would be curious to know
what code this patch is based on. There are other things that have changed from
a few spot checks. Looks like it really needs a rewrite and a complete set of
unit tests.
Performance work for these classes is kind of tricky (learned working on 8670)
because code generation is heavily impacted by things like CHA which determine
what kind of inlining (if any) you get for the implementation of methods. If we
are going to churn this code I think it requires some thought into how it
should work and how each method is going to get inlined properly. I am
wondering if it can be transformed into a channel that can be fed to the code
from CASSANDRA-8670. Things are definitely jumbled right now with the streams
conflated with compression and file IO and buffering.
[~benedict] might have an opinion on whether we should try to use the code
added for 8670 in RandomAccessReader or whether we should try and improve
AbstractDataInput and things that use it.
> Faster sequential IO (on compaction, streaming, etc)
> ----------------------------------------------------
>
> Key: CASSANDRA-8630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8630
> Project: Cassandra
> Issue Type: Improvement
> Components: Core, Tools
> Reporter: Oleg Anastasyev
> Assignee: Oleg Anastasyev
> Labels: performance
> Attachments: 8630-FasterSequencialReadsAndWrites.txt, cpu_load.png
>
>
> When node is doing a lot of sequencial IO (streaming, compacting, etc) a lot
> of CPU is lost in calls to RAF's int read() and DataOutputStream's write(int).
> This is because default implementations of readShort,readLong, etc as well as
> their matching write* are implemented with numerous calls of byte by byte
> read and write.
> This makes a lot of syscalls as well.
> A quick microbench shows than just reimplementation of these methods in
> either way gives 8x speed increase.
> A patch attached implements RandomAccessReader.read<Type> and
> SequencialWriter.write<Type> methods in more efficient way.
> I also eliminated some extra byte copies in CompositeType.split and
> ColumnNameHelper.maxComponents, which were on my profiler's hotspot method
> list during tests.
> A stress tests on my laptop show that this patch makes compaction 25-30%
> faster on uncompressed sstables and 15% faster for compressed ones.
> A deployment to production shows much less CPU load for compaction.
> (I attached a cpu load graph from one of our production, orange is niced CPU
> load - i.e. compaction; yellow is user - i.e. not compaction related tasks)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
