[
https://issues.apache.org/jira/browse/HBASE-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-16703:
-----------------------------------
Description: In read workloads 35% of the allocation pressure produced by
servicing RPC requests, when block encoding is enabled, comes from
BufferedDataBlockEncoder$SeekerState.<init>, where we allocate two byte arrays
of INITIAL_KEY_BUFFER_SIZE in length. There's an opportunity for object pooling
of SeekerState here. Subsequent code checks if those byte arrays are sized
sufficiently to handle incoming data to copy. The arrays will be resized if
needed. (was: In read workloads 35% of the allocation pressure produced by
servicing RPC requests, when block encoding is enabled, comes from
SeekerState.<init> of the DataBlockEncoder implementation currently in use,
where we allocate two byte arrays of INITIAL_KEY_BUFFER_SIZE in length. There's
an opportunity for object pooling of SeekerState here. Subsequent code checks
if those byte arrays are sized sufficiently to handle incoming data to copy.
The arrays will be resized if needed. )
> Explore object pooling of SeekerState
> -------------------------------------
>
> Key: HBASE-16703
> URL: https://issues.apache.org/jira/browse/HBASE-16703
> Project: HBase
> Issue Type: Task
> Reporter: Andrew Purtell
>
> In read workloads 35% of the allocation pressure produced by servicing RPC
> requests, when block encoding is enabled, comes from
> BufferedDataBlockEncoder$SeekerState.<init>, where we allocate two byte
> arrays of INITIAL_KEY_BUFFER_SIZE in length. There's an opportunity for
> object pooling of SeekerState here. Subsequent code checks if those byte
> arrays are sized sufficiently to handle incoming data to copy. The arrays
> will be resized if needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
