[jbossts-issues] [JBoss JIRA] (JBTM-1340) BeanPopulator overhead needs looking into

Jonathan Halliday (JIRA) jira-events at lists.jboss.org
Thu Nov 8 05:55:19 EST 2012


    [ https://issues.jboss.org/browse/JBTM-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732678#comment-12732678 ] 

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
                
> BeanPopulator overhead needs looking into
> -----------------------------------------
>
>                 Key: JBTM-1340
>                 URL: https://issues.jboss.org/browse/JBTM-1340
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Common
>    Affects Versions: 4.17.2
>         Environment: Mac OS 10.7
>            Reporter: Mark Little
>            Assignee: Tom Jenkinson
>             Fix For: 5.0.0.Final
>
>
> 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

--
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



More information about the jbossts-issues mailing list