[
https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618339#action_12618339
]
funtick edited comment on SOLR-665 at 7/30/08 7:06 AM:
-----------------------------------------------------------
Noble, thanks for feedback!
Of course my code is buggy but I only wanted _to illustrate_ simplest idea; I
am extremely busy with other staff (Liferay) and can't focus on SOLR
improvements... may be during weekend.
bq. ...will always evaluate to false. And the reference will always have one
value
- yes, this is bug. There are other bugs too...
bq. We must be removing the entry which was accessed first (not last)..
I mean (and code too) the same; probably wrong wording
bq. And the static volatile counter is not threadsafe.
Do we _really-really_ need thread safety here? By using 'volatile' I only
prevent _some_ JVMs from trying to optimize some code (and cause problems with
per-instance variables which never change).
bq. There is no need to use a WeakReference anywhere
Agree...
bq. To get that you must maintian a linkedlist the way linkedhashmap maintains.
No other shortcut.
May be... but looks similar to Arrays.sort(), or TreeSet, and etc.... I am
trying to avoid this. 'No other shortcut' - may be, but I am unsure.
Thanks!
was (Author: funtick):
Nobble, thanks for feedback!
Of course my code is buggy but I only wanted _to illustrate_ simplest idea; I
am extremely busy with other staff (Liferay) and can't focus on SOLR
improvements... may be during weekend.
bq. ...will always evaluate to false. And the reference will always have one
value
- yes, this is bug. There are other bugs too...
bq. We must be removing the entry which was accessed first (not last)..
I mean (and code too) the same; probably wrong wording
bq. And the static volatile counter is not threadsafe.
Do we _really-really_ need thread safety here? By using 'volatile' I only
prevent _some_ JVMs from trying to optimize some code (and cause problems with
per-instance variables which never change).
bq. There is no need to use a WeakReference anywhere
Agree...
bq. To get that you must maintian a linkedlist the way linkedhashmap maintains.
No other shortcut.
May be... but looks similar to Arrays.sort(), or TreeSet, and etc.... I am
trying to avoid this. 'No other shortcut' - may be, but I am unsure.
Thanks!
> 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: ConcurrentFIFOCache.java, ConcurrentFIFOCache.java,
> ConcurrentLRUCache.java, ConcurrentLRUWeakCache.java,
> ConcurrentLRUWeakCache.java, ConcurrentLRUWeakCache.java, 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.
