[JBoss JIRA] Created: (ISPN-1429) remove lock guards(if trace.enabled() .. ) where possible
by Mircea Markus (JIRA)
remove lock guards(if trace.enabled() .. ) where possible
---------------------------------------------------------
Key: ISPN-1429
URL: https://issues.jboss.org/browse/ISPN-1429
Project: Infinispan
Issue Type: Enhancement
Reporter: Mircea Markus
Assignee: Manik Surtani
Citing from David Lloyd's email:
<snip>
If you're using the jboss-logging API, and your log statement does not
do any interpolation, then it is just as fast to do any of the following
(with no if):
log.trace("blah");
log.tracef("the %s happened to %s", foo, bar);
log.tracev("the {0} happened to {1}", foo, bar);
In the case where trace logging is disabled, these are exactly as
efficient as the if (log.isTraceEnabled()) variants. In the case where
it is enabled, it is marginally more efficient (though the trace log
itself is substantially more expensive of course).
Overall I'd avoid the "if" forms unless you're doing complex interpolation:
log.trace("Foo " + bar + " baz " + zap);
log.tracef("the %s happened to %s", fooMethod().barMethod(), bar);
...both of which incur the expense of the expression resolution even if
the log message is ultimately discarded.
</snip>
This JIRA is about:
1. removing all the "if (trace)" statements from the code (where possible, see below)
2. making sure that this is a documented policy and people are aware of it
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (ISPN-1542) InvocationContext should not keep entries in an BidirectionalLinkedHashMap
by Mircea Markus (Created) (JIRA)
InvocationContext should not keep entries in an BidirectionalLinkedHashMap
--------------------------------------------------------------------------
Key: ISPN-1542
URL: https://issues.jboss.org/browse/ISPN-1542
Project: Infinispan
Issue Type: Feature Request
Reporter: Mircea Markus
Assignee: Manik Surtani
ATM the InvocationContext keeps the looked up entries in an BidirectionalLinkedHashMap. It uses the BidirectionalLinkedHashMap in order to commit the entries in the reversed order in which they were added to the context. This is an inherited feature from JBossCache, where it made sense due to cache's tree structure. It doesn't make sense in Infinispan though, and it adds an unnecessary burden to the InvocationContext.
The problem is particularly performance costly in the case of non-tx caches, where most of the operations only need a single entry lookup to be held in the invocation context.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (ISPN-1309) Provide a way to use Flags without resorting to a ThreadLocal
by Sanne Grinovero (JIRA)
Provide a way to use Flags without resorting to a ThreadLocal
-------------------------------------------------------------
Key: ISPN-1309
URL: https://issues.jboss.org/browse/ISPN-1309
Project: Infinispan
Issue Type: Feature Request
Reporter: Sanne Grinovero
Assignee: Manik Surtani
Fix For: 6.0.0.FINAL
A brief performance analysis highlighted a significant impact on performance because of the use of ThreadLocals to hold the enabled flags in the current context.
We should check these findings with a proper test and provide an alternative way, ideally one which doesn't need to lookup in the flagHolder either (avoid both the put and the get in the threadlocal).
We'll need a method which returns a new Cache instance having the mentioned Flags always implicitly added to the invocation context. I think it would be fine in such an alternative implementation to not support dynamic flags.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months