[
https://issues.apache.org/jira/browse/HBASE-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14905005#comment-14905005
]
stack commented on HBASE-14470:
-------------------------------
bq. I am wondering, is there any way to optimize protobuf - generated stubs?
These classes just pollute Java heap.
The stubs have served their purpose -- providing a narrow border between app
and RPC+PB. We could now discard this interface and bolt app to rpc (after
doing a bit of design). Ideally, server sends Results only and a Result is
nothing but how many Cells and if we are chunking. Even more ideal, we'd just
send Cells... with a bit of enveloping with meta data... sizing.... partial...
http2!
> Reduce memory pressure generated by client
> ------------------------------------------
>
> Key: HBASE-14470
> URL: https://issues.apache.org/jira/browse/HBASE-14470
> Project: HBase
> Issue Type: Task
> Components: Client, Performance
> Affects Versions: 1.3.0
> Reporter: Nick Dimiduk
> Attachments: allocation-by-class.jpg, allocation-by-thread.jpg,
> c+ma.jfc, object-stats.jpg
>
>
> I think there's room for improvement in our client's memory profile. I ran
> ltt with jfr running, attaching some snaps of what my client sees. Looks like
> some kind of object pool or block encoding for result objects will give us a
> lot of bang for the buck re: allocations and GC pressure. We probably also
> want to look for an alternative way to represent result objects, something
> besides the java Map interface with it's Entry bloat.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
