[
https://issues.apache.org/jira/browse/CASSANDRA-15215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437456#comment-17437456
]
Benedict Elliott Smith edited comment on CASSANDRA-15215 at 11/2/21, 8:42 PM:
------------------------------------------------------------------------------
If we're improving the benchmark we might also want to consider increasing the
morphism of the call sites, i.e. randomly supplying either a
{{DirectByteBuffer}} or {{HeapByteBuffer}}, and maybe even a
{{MappedByteBuffer}} to make it megamorphic.
Preferably we would have three benchmarks, namely monomorphic (HeapByteBuffer
only), bimorphic (HeapByteBuffer and DirectByteBuffer selected randomly),
megamorphic (HBB, DBB and MappedByteBuffer))
The {{DataOutput}} variants of the test can similarly be updated to pick two or
three variants.
FWIW, my expectation is that there will be no relative difference between
approaches at different levels of morphism, but HotSpot _might_ make poor
decisions particularly for the above {{ByteBuffer}} approach. We could also
just check the byte code, but that is only a snapshot of HotSpot's
decision-making, and its validity depends on us not changing the code to break
it (not that we unfortunately currently monitor these benchmarks for
regressions).
was (Author: benedict):
If we're improving the benchmark we might also want to consider increasing the
morphism of the call sites, i.e. randomly supplying either a
{{DirectByteBuffer}} or {{HeapByteBuffer}}, and maybe even a
{{MappedByteBuffer}} to make it megamorphic.
Preferably we would have three benchmarks, namely monomorphic (HeapByteBuffer
only), bimorphic (HeapByteBuffer and DirectByteBuffer selected randomly),
megamorphic (HBB, DBB and MappedByteBuffer))
The {{DataOutput}} variants of the test can similarly be updated to pick two or
three variants.
> VIntCoding should read and write more efficiently
> -------------------------------------------------
>
> Key: CASSANDRA-15215
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15215
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction, Local/SSTable
> Reporter: Benedict Elliott Smith
> Assignee: Aleksandr Sorokoumov
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.x
>
>
> Most vints occupy significantly fewer than 8 bytes, and most buffers have >=
> 8 bytes spare, in which case we can construct the relevant bytes in a
> register and memcpy them to the correct position. Since we read and write a
> lot of vints, this waste is probably measurable, particularly during
> compaction and flush, and can probably be considered a performance bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
