[
https://issues.apache.org/jira/browse/HBASE-12117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152872#comment-14152872
]
stack commented on HBASE-12117:
-------------------------------
So the focus is on 17% of overall CPU -- the finishSetup of HTable -- and of
this most is just getting Configuration. Yuck. This is our making an HTable
instance per session? We keep it around? HTable ain't that lightweight then?
Any chance of caching some config in Connection for instance?
> Constructors that use Configuration may be harmful
> --------------------------------------------------
>
> Key: HBASE-12117
> URL: https://issues.apache.org/jira/browse/HBASE-12117
> Project: HBase
> Issue Type: Improvement
> Reporter: Andrew Purtell
> Attachments: traces.client.c.svg, traces.client.getHTable.svg
>
>
> There's a common pattern in HBase code where in the constructor, or in an
> initialization method also called once per instantiation, or both, we look up
> values from Hadoop Configuration and store them into fields. This can be
> expensive if the object is frequently created. Configuration is a heavyweight
> registry that does a lot of string operations and regex matching. See
> attached example. Method calls into Configuration account for 48.25% of CPU
> time when creating the HTable object in 0.98. (The remainder is spent
> instantiating the RPC controller via reflection, a separate issue that merits
> followup elsewhere.) Creation of HTable instances is expected to be a
> lightweight operation if a client is using unmanaged HConnections; however
> creating HTable instances takes up about 18% of the client's total on-CPU
> time. This is just one example where constructors that use Configuration may
> be harmful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
