]
Tristan Tarrant updated ISPN-2414:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Optimise memory hotspots for local caches
-----------------------------------------
Key: ISPN-2414
URL:
https://issues.jboss.org/browse/ISPN-2414
Project: Infinispan
Issue Type: Enhancement
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.2.0.Beta3, 5.2.0.Final, 5.1.9.Final
Attachments: Screen Shot 2012-10-17 at 1.21.48 PM.png, Screen Shot 2012-10-17 at
1.25.45 PM.png, Screen Shot 2012-10-17 at 1.30.09 PM.png, Screen Shot 2012-10-17 at
1.33.46 PM.png
Several small memory hotspots have been discovered during some performance testing of
local caches. Optimise them.
1. Collections.EmptySet.Iterator: Screen%20Shot%202012-10-17%20at%201.21.48%20PM.png
- First of all, iterating over an empty set returns a brand new iterator instance all the
time. WTF?
- Second, why does get() have to call unlockAll()? We do not acquire locks on get (unless
it has a FORCE_WRITE_LOCK flag on it), right?
2. ThreadLocal.set: Screen%20Shot%202012-10-17%20at%201.25.45%20PM.png
- Is this neeeded at all?
- If it's needed for any use case, can it be optimised away to avoid using it for a
local cache where no marshaller is used, and where no cluster cache loader is used?
3. AbstractInvocationContext instances:
Screen%20Shot%202012-10-17%20at%201.30.09%20PM.png
- Why is this expensive? Is it cos the reference to the ClassLoader?
- If it's the ClassLoader ref, can we move this away for local caches?
4. AbstractFlagAffectedCommand instances:
Screen%20Shot%202012-10-17%20at%201.33.46%20PM.png
- Might be worth thinking how can we shrink these commands for local, unflagged,
operations, such as 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: