Single processor pentium 4? Shouldn't someone benchmark this with tech
from this century:) you know some comps are not room size now right?
Not being very serious...
- Mark
On Nov 2, 2008, at 10:34 AM, "Yonik Seeley (JIRA)" <[EMAIL PROTECTED]>
wrote:
[ https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644594#action_12644594
]
Yonik Seeley commented on SOLR-667:
-----------------------------------
bq. Isn't it too expensive to create a potentially huge array every
time we do a clean? (too much work for GC)
That's what benchmarking is for :-)
It's a single short-lived allocation that allows us to greatly
reduce the number of elements we need to evaluate on successive
passes. Inserts into a TreeSet may have a higher GC cost given it's
an allocation per insert.
Alternate LRUCache implementation
---------------------------------
Key: SOLR-667
URL: https://issues.apache.org/jira/browse/SOLR-667
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Yonik Seeley
Fix For: 1.4
Attachments: ConcurrentLRUCache.java,
ConcurrentLRUCache.java, ConcurrentLRUCache.java, SOLR-667-
alternate.patch, SOLR-667-alternate.patch, SOLR-667-updates.patch,
SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch,
SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch,
SOLR-667.patch
The only available SolrCache i.e LRUCache is based on
_LinkedHashMap_ which has _get()_ also synchronized. This can cause
severe bottlenecks for faceted search. Any alternate implementation
which can be faster/better must be considered.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
