[
https://issues.apache.org/jira/browse/UIMA-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor resolved UIMA-3619.
----------------------------------
Resolution: Fixed
Changes: switched to internal hash code derived from murmurhash3 (in public
domain); this eliminates all volatile / atomic operations. Changed the hash
bucket collision algorithm to one that is more favorable to L1/L2/L3 caches -
using triangular numbers. For the case where a lookup fails, and then a new
cover instance is added to the table, avoided re-looking up to find the spot to
add the new item.
> improve Cas FS to JCas cover instance map
> -----------------------------------------
>
> Key: UIMA-3619
> URL: https://issues.apache.org/jira/browse/UIMA-3619
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Affects Versions: 2.5.0SDK
> Reporter: Marshall Schor
> Assignee: Marshall Schor
> Priority: Minor
> Fix For: 2.5.1SDK
>
>
> In highly parallel environments running on multiple cores, profiling shows
> that the JCas map has performance issues due to volatile and atomic
> operations that are unneeded, but happen due to the use of the built-in Java
> Random function (which uses volatile and atomic operations, internally). This
> map doesn't need to support multi-threading operations - it is always used in
> a single-thread manner. Other optimizations are possible, due to the limited
> way this table is used. One of the common cases is an iterator fetching an
> existing FS from the CAS, and needing to supply the corresponding JCas object
> (if it exists). This operation first looks up in the Map using the address
> as the key, and if not found, then makes the JCas object, and then adds it to
> the map - an operation which repeats the same lookup in order to find the
> "empty slot" where it can store the item. This extra lookup can be
> eliminated.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
