[ https://issues.apache.org/jira/browse/CASSANDRA-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17012330#comment-17012330 ]
Jordan West commented on CASSANDRA-15213: ----------------------------------------- My working branch is here: [https://github.com/jrwest/cassandra/tree/jwest/15213] I've implemented the binary search replacement. Didn't make an attempt at going branchless but even as implemented its faster than the existing implementation. Working on the striping / replacement of {{LongAdder[]}} and will share when ready. {code:java} Trunk: [java] Benchmark Mode Cnt Score Error Units [java] LatencyTrackingBench.benchInsertToDEHR thrpt 5 21887453.678 ± 2108481.285 ops/s [java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5 8908817.316 ± 115453.642 ops/s 15213 (linear search changes only): [java] Benchmark Mode Cnt Score Error Units [java] LatencyTrackingBench.benchInsertToDEHR thrpt 5 24646022.304 ± 1052105.818 ops/s [java] LatencyTrackingBench.benchLatencyMetricsWrite thrpt 5 9175928.594 ± 269984.204 ops/s {code} > DecayingEstimatedHistogramReservoir Inefficiencies > -------------------------------------------------- > > Key: CASSANDRA-15213 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15213 > Project: Cassandra > Issue Type: Bug > Components: Observability/Metrics > Reporter: Benedict Elliott Smith > Assignee: Jordan West > Priority: Normal > Fix For: 4.0-beta > > > * {{LongAdder}} introduced to trunk consumes 9MiB of heap without user > schemas, and this will grow significantly under contention and user schemas > with many tables. This is because {{LongAdder}} is a very heavy class > designed for single contended values. > ** This can likely be improved significantly, without significant loss of > performance in the contended case, by simply increasing the size of our > primitive backing array and providing multiple buckets, with each thread > picking a bucket to increment, or simply multiple backing arrays. Probably a > better way still to do this would be to introduce some competition detection > to the update, much like {{LongAdder}} utilises, that increases the number of > backing arrays under competition. > ** To save memory this approach could partition the space into chunks that > are likely to be updated together, so that we do not need to duplicate the > entire array under competition. > * Similarly, binary search is costly and a measurable cost as a share of the > new networking work (without filtering it was > 10% of the CPU used overall). > We can compute an approximation floor(log2 n / log2 1.2) extremely cheaply, > to save the random memory access costs. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org