[
https://issues.apache.org/jira/browse/PHOENIX-6670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509001#comment-17509001
]
Istvan Toth commented on PHOENIX-6670:
--------------------------------------
>From what I learned while poring over the HBase codebase, the only reason to
>copy a cell to a KV is to decouple the cell from the underlying ByteBuffer's
>lifecycle.
Otherwise AFAIK Cells and KVs are interchangeable. (save some perf
optimizations that are used for off-heap cells)
I may be missing something, and there may be other reasons for doing that, but
I can't think of any right now.
Maybe in early versions of the off-heap work all Cells were off-heap and the
code was just never updated ?
I haven't actually tested this, and we may also need to update some other code
in Phoenix to allow Cells instead of requiring KVs explicitly, but I wouldn't
expect that to cause problems.
> Optimize PhoenixKeyValueUtil#maybeCopyCell
> ------------------------------------------
>
> Key: PHOENIX-6670
> URL: https://issues.apache.org/jira/browse/PHOENIX-6670
> Project: Phoenix
> Issue Type: Improvement
> Components: core
> Affects Versions: 5.2.0
> Reporter: Istvan Toth
> Priority: Major
>
> PhoenixKeyValueUtil#maybeCopyCell copies every cell that is not a KeyValue to
> a keyValue.
> It's point is to copy Off-Heap cells to the Heap, so that the values are kept
> after the backing ByteBuffer is freed, and we avoid use-after-free errors.
> However, checking if a Cell is a KeyValue instance is a poor indication for
> that, as there are a lot of Cell types that are not KeyValues, but are stored
> on the heap, and do not need to be copied.
> Copying only ByteBufferExtendedCell instances instead would potentially be a
> significat performance gain.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
