[ https://issues.jboss.org/browse/JBTM-1340?page=com.atlassian.jira.plugin.... ] Mark Little updated JBTM-1340: ------------------------------ Description: During profiling, BeanPopulator can represent a 7% overhead. It may not seem like a lot, but for something as relatively simple as what BeanPopulator should be doing, it seems to be quite a bit. 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.coordinator.TxStats.enabled 6.9% - 4,477 ms - 10,000 inv. com.arjuna.ats.arjuna.common.arjPropertyManager.getCoordinatorEnvironmentBean 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getDefaultInstance 6.9% - 4,476 ms - 10,000 inv. com.arjuna.common.internal.util.propertyservice.BeanPopulator.getNamedInstance 2.5% - 1,587 ms - 10,000 inv. java.lang.StringBuilder.<init> 2.3% - 1,507 ms - 10,000 inv. java.lang.StringBuilder.toString 0.0% - 320 µs - 10,000 inv. java.util.concurrent.ConcurrentMap.containsKey 0.0% - 61 µs - 10,000 inv. java.lang.Class.getName 0.0% - 25 µs - 10,000 inv. java.util.concurrent.ConcurrentMap.get was:During profiling, BeanPopulator can represent a 7% overhead. It may not seem like a lot, but for something as relatively simple as what BeanPopulator should be doing, it seems to be quite a bit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBTM-1340?page=com.atlassian.jira.plugin.... ] Jonathan Halliday commented on JBTM-1340: ----------------------------------------- The problem is actually TxStats rather than the BeanPopulator. The cost for most properties is indeed one-off, as the point of use reads the property value once at startup and caches it, so the bean is not resolved per use. TxStats is an experiment of sorts - it's the only property that is runtime dynamic - changes to the property in the bean have immediate effect, no restart required. To achieve that there are two approaches - cache the bean reference and rely on the property field being volatile, or resolve the bean each time. TxStats currently does the latter, on the basis that it's the required approach where you want to atomically change a group of properties at the same time by replacing the entire bean instance. Where only a single property is involved you can go for the simpler method of caching the bean reference. Change TxStatus to cache the bean and the problem goes away, but you cease to get any useful information regarding the potential implementation costs of the different approaches. https://community.jboss.org/message/624088 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBTM-1340?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1340: -------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira