You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Rick Curtis (JIRA)" <ji...@apache.org> on 2010/11/08 23:52:23 UTC

[jira] Resolved: (OPENJPA-1872) Optimize CacheMap read performance

     [ https://issues.apache.org/jira/browse/OPENJPA-1872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Curtis resolved OPENJPA-1872.
----------------------------------

    Resolution: Fixed

> Optimize CacheMap read performance
> ----------------------------------
>
>                 Key: OPENJPA-1872
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1872
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: performance
>    Affects Versions: 2.1.0
>            Reporter: Rick Curtis
>            Assignee: Rick Curtis
>            Priority: Minor
>             Fix For: 2.1.0
>
>
> While digging through a profile I noticed that for every CacheMap.get(..) call where there is a hit, I was seeing two underlying ConcurrentHashMap.get method calls. This is because we always look to see if a given key exists in the pinned map before looking in the main map. As the code stands today, it is optimized for the existence of entries in the pinned map and I think that is an incorrect assumption.
> With this JIRA I'm going to optimize the get(...), containsKey(...), and containsValue(...) to check the main map for results before looking at the pinned map. In a micro benchmark I observed approximately a 20% improvement in the time required to call get(...) when there is a hit.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.