[
https://issues.apache.org/jira/browse/CASSANDRA-15215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17436528#comment-17436528
]
Benedict Elliott Smith edited comment on CASSANDRA-15215 at 10/31/21, 6:28 PM:
-------------------------------------------------------------------------------
Worth noting that the relative performance of the {{ByteBuffer}} variants is
probably harder to predict, and depends a lot on how smart HotSpot is, and the
morphism of the call-sites.
Also, your approach already appears to be an improvement over the status quo
which is great! Though it might be less impressive for {{DataOutput}} due to
the greater complexity of implementation for their corresponding methods. I
think it is _likely_ that they will all be monomorphic call-sites which should
mitigate it, but they may have to potentially invoke {{flush()}} multiple times
which at minimum leads to much larger methods.
was (Author: benedict):
(Worth noting that the relative performance of the {{ByteBuffer}} variants is
probably harder to predict, and depends a lot on how smart HotSpot is, and the
morphism of the call-sites)
> 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]
