[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-12128: -- Fix Version/s: (was: 1.0.0) Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 1.0.0, 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 2.0.0, 0.99.2 Attachments: HBASE-12128.v1-1.0.patch, HBASE-12128.v1-2.0.patch, HBASE-12128.v2-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Fix Version/s: 1.0.0 Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 1.0.0, 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 1.0.0, 2.0.0, 0.99.2 Attachments: HBASE-12128.v1-1.0.patch, HBASE-12128.v1-2.0.patch, HBASE-12128.v2-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-12128: -- Resolution: Fixed Fix Version/s: (was: 1.0.0) 0.99.2 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) I've pushed this to branch-1+. Forgot to quote you [~syuanjiang] as the author in the commit msg, sorry about that. Anyway thanks for the patch, and thanks for reviews. Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 1.0.0, 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 2.0.0, 0.99.2 Attachments: HBASE-12128.v1-1.0.patch, HBASE-12128.v1-2.0.patch, HBASE-12128.v2-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Affects Version/s: 2.0.0 Status: Patch Available (was: In Progress) Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 1.0.0, 2.0.0, 0.98.9, 0.99.2 Attachments: HBASE-12128.v1-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Attachment: HBASE-12128.v2-2.0.patch V2 patch fixed the checkstyle issue and unit test failure. Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 1.0.0, 2.0.0, 0.98.9, 0.99.2 Attachments: HBASE-12128.v1-2.0.patch, HBASE-12128.v2-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Status: Patch Available (was: In Progress) Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 1.0.0, 2.0.0, 0.98.9, 0.99.2 Attachments: HBASE-12128.v1-2.0.patch, HBASE-12128.v2-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Status: In Progress (was: Patch Available) Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 1.0.0, 2.0.0, 0.98.9, 0.99.2 Attachments: HBASE-12128.v1-2.0.patch, HBASE-12128.v2-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Attachment: HBASE-12128.v1-1.0.patch Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 1.0.0, 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 1.0.0, 2.0.0 Attachments: HBASE-12128.v1-1.0.patch, HBASE-12128.v1-2.0.patch, HBASE-12128.v2-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Fix Version/s: (was: 0.99.2) (was: 0.98.9) Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 1.0.0, 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 1.0.0, 2.0.0 Attachments: HBASE-12128.v1-1.0.patch, HBASE-12128.v1-2.0.patch, HBASE-12128.v2-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Affects Version/s: 1.0.0 Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Affects Versions: 1.0.0, 2.0.0 Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 1.0.0, 2.0.0 Attachments: HBASE-12128.v1-1.0.patch, HBASE-12128.v1-2.0.patch, HBASE-12128.v2-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Attachment: HBASE-12128.v1-2.0.patch The V1 patch for 2.0.0 caches table configuration information in Connection. To improve performance, the table configuration, RpcRetryingCallerFactory, RpcControllerFactory are passed in to HTable so that HTable object would not need to construct those objects during construction time. Note: this only applies to the new style Connection#getTable for performance gain; for the old style that directly call HTable constructor, the code would stay the same (aka no performance change). Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 2.0.0, 0.98.9, 0.99.2 Attachments: HBASE-12128.v1-2.0.patch Original Estimate: 120h Remaining Estimate: 120h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Fix Version/s: 1.0.0 Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 1.0.0, 2.0.0, 0.98.9, 0.99.2 Attachments: HBASE-12128.v1-2.0.patch Original Estimate: 120h Time Spent: 72h Remaining Estimate: 48h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang updated HBASE-12128: --- Remaining Estimate: 120h Original Estimate: 120h Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Assignee: Stephen Yuan Jiang Fix For: 2.0.0, 0.98.9, 0.99.2 Original Estimate: 120h Remaining Estimate: 120h Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-12128: --- Fix Version/s: (was: 0.98.8) 0.98.9 Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Fix For: 2.0.0, 0.98.9, 0.99.2 Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-12128: -- Fix Version/s: (was: 0.99.1) 0.99.2 Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Fix For: 2.0.0, 0.98.8, 0.99.2 Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12128) Cache configuration and RpcController selection for Table in Connection
[ https://issues.apache.org/jira/browse/HBASE-12128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-12128: --- Fix Version/s: 0.99.1 0.98.8 2.0.0 Schedule this so it gets looked at Cache configuration and RpcController selection for Table in Connection --- Key: HBASE-12128 URL: https://issues.apache.org/jira/browse/HBASE-12128 Project: HBase Issue Type: Sub-task Reporter: Andrew Purtell Fix For: 2.0.0, 0.98.8, 0.99.1 Creating Table instances should be lightweight. Apps that manage their own Connections are expected to create Tables on demand for each interaction. However we look up values from Hadoop Configuration when constructing Table objects for storing to some of its fields. Configuration is a heavyweight registry that does a lot of string operations and regex matching. Method calls into Configuration account for 48.25% of CPU time when creating the HTable object in 0.98. Another ~48% of CPU is spent constructing the desired RpcController object via reflection in 0.98. Together this can account for ~20% of total on-CPU time of the client. See parent issue for more detail. We are using Connection like a factory for Table. We should cache configuration for Table in Connection. We should also create by reflection once and cache the desired RpcController object, and clone it for new Tables. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
