[
https://issues.apache.org/jira/browse/CASSANDRA-20428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935467#comment-17935467
]
Benedict Elliott Smith commented on CASSANDRA-20428:
----------------------------------------------------
[~rustyrazorblade], like Blake I'm not sure Arenas are all that helpful here.
Arenas are to help address native memory management, and the vast majority of
the costs we pay here are in the (java) object model. As it happens, I am
fairly sure Nitsan's patch already manages the raw bytes without any overhead,
by copying them into a small temporary buffer. I am sure this can be improved
further, but I cannot see how an Arena would improve this all that much.
{{MemorySegment}} _does_ appear to be slightly more efficient than
{{ByteBuffer}}, so if we migrated wholesale away from {{ByteBuffer}} we would
reduce our per-cell overheads, but they would still be much too high.
To improve our memory usage, we need to altogether stop inflating such a
complex object model. I see basically two avenues for major improvement,
besides the already-discussed format changes that would enable directly copying
bytes:
1. As I proposed back in NGCC something like 2012, we start building our
intermediate results natively in a byte-addressable format, building up column
and row values in a single buffer. This isn't all that hard really in
principle, but it is a lot of work. We would have to move wholesale from an
Iterator design to a Cursor design (which is anyway superior). Arenas are
compatible with this, but sort of orthogonal.
2. Use ASM to compile Row objects with native types for the fields, with a
couple of specialisations for e.g. the presence of TTLs or cell level
timestamps. This would dramatically shrink the per-cell memory overheads, and
likely speed up reading/writing. This might be less work, as we can still
operate on "Row" objects, but we would need to move away from ByteBuffer as an
intermediate format, and introduce methods for directly moving cell contents
between Row objects.
> Eliminate byte array allocation in ByteArrayAccessor.read
> ---------------------------------------------------------
>
> Key: CASSANDRA-20428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20428
> Project: Apache Cassandra
> Issue Type: Improvement
> Reporter: Jon Haddad
> Priority: Normal
> Attachments: allocation-reverse.html,
> image-2025-03-11-11-05-55-378.png
>
>
> During compaction we allocate a new byte[] in ByteArrayAccessor.read. This
> is one of the hottest paths in the codebase, hit during writes, compaction,
> creating tables, and possibly others. In my performance tests using default
> compaction settings of 64MB I see this responsible for 40% of allocations.
> This is largely what drives GC pause frequency and duration. If we are able
> to eliminate the O(N) allocations performed here, this might be one of the
> best optimizations we could do for the number of things it touches.
> Allocation profile attached.
> !image-2025-03-11-11-05-55-378.png|width=514,height=269!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
