[
https://issues.apache.org/jira/browse/CASSANDRA-8630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702755#comment-14702755
]
Benedict commented on CASSANDRA-8630:
-------------------------------------
bq. They are serialized in the summary but here we don't need to keep backward
compatibility as it will be recreated on the flight, correct?
Right, but we'll need to deserialize the information still (and just throw it
away)
bq. You prefer the binary search due to the cost of the map?
Primarily in lookup time. The algorithmic complexity is the same, but the
constant factor is much larger with a TreeMap, as you have at least two cache
misses for each decision, whereas with a primitive binary search, we'll have
between 0 and 1. There's also no boxing required for the parameter. There are
other benefits, but none that are likely meaningful here, and even this isn't
super important, it's just something that has bugged me. _If_ we go with
mapping once, on first use (i.e. never remapping the same region, as we
currently do), we may end up with many more segments (one per 50Mb or so, by
default), and so efficiency would be a little more important.
> 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: Stefania
> Labels: compaction, performance
> Fix For: 3.x
>
> Attachments: 8630-FasterSequencialReadsAndWrites.txt, cpu_load.png,
> flight_recorder_001_files.tar.gz, flight_recorder_002_files.tar.gz,
> mmaped_uncomp_hotspot.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)
