[
https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617664#action_12617664
]
Fuad Efendi commented on SOLR-665:
----------------------------------
bq. It is if nothing is modifying the map during the get. If something is
modifying the map you don't know how the implementation handles the insert of a
new value. It might copy the object, and you'd end up with half an object or
even an invalid memory location. That's why the javadoc says that you must
synchronize accesses if anything modifies the map - this is not limited to
iterators.
JavaDoc does not say that. Instead, it says (I am repeating):
bq. ..and at least one of the threads modifies the map structurally, it must be
synchronized externally.
- only thread doing structural modification must be synchronized. In case of
LinkedHashMap, for instance, we need to synchronize inserts in order to avoid
Entry instances referencing themselves (orphans).
bq. you don't know how the implementation handles the insert of a new value
I know exactly: SOLR does not modify 'value' during 'insert', Map.Entry
instances are immutable in SOLR, etc. Table resize is main problem - but after
analyzing source code I don't see any problem. Consern that 'wrong value will
be returned for a key' is not applicable. And JavaDocs does not say anything
about that. Collections internally use Map.Entry in an immutable way, do not
change it.
> FIFO Cache (Unsynchronized): 9x times performance boost
> -------------------------------------------------------
>
> Key: SOLR-665
> URL: https://issues.apache.org/jira/browse/SOLR-665
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.3
> Environment: JRockit R27 (Java 6)
> Reporter: Fuad Efendi
> Attachments: FIFOCache.java
>
> Original Estimate: 672h
> Remaining Estimate: 672h
>
> Attached is modified version of LRUCache where
> 1. map = new LinkedHashMap(initialSize, 0.75f, false) - so that
> "reordering"/true (performance bottleneck of LRU) is replaced to
> "insertion-order"/false (so that it became FIFO)
> 2. Almost all (absolutely unneccessary) synchronized statements commented out
> See discussion at
> http://www.nabble.com/LRUCache---synchronized%21--td16439831.html
> Performance metrics (taken from SOLR Admin):
> LRU
> Requests: 7638
> Average Time-Per-Request: 15300
> Average Request-per-Second: 0.06
> FIFO:
> Requests: 3355
> Average Time-Per-Request: 1610
> Average Request-per-Second: 0.11
> Performance increased 9 times which roughly corresponds to a number of CPU in
> a system, http://www.tokenizer.org/ (Shopping Search Engine at Tokenizer.org)
> Current number of documents: 7494689
> name: filterCache
> class: org.apache.solr.search.LRUCache
> version: 1.0
> description: LRU Cache(maxSize=10000000, initialSize=1000)
> stats: lookups : 15966954582
> hits : 16391851546
> hitratio : 0.102
> inserts : 4246120
> evictions : 0
> size : 2668705
> cumulative_lookups : 16415839763
> cumulative_hits : 16411608101
> cumulative_hitratio : 0.99
> cumulative_inserts : 4246246
> cumulative_evictions : 0
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
