[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644594#action_12644594
]
[EMAIL PROTECTED] edited comment on SOLR-667 at 11/2/08 7:39 AM:
------------------------------------------------------------
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.
bq. May be we do not even need it if the first loop is enough.
Right... although in my testing, it seemed like the first loop was rarely
sufficient (although the second often was).
was (Author: [EMAIL PROTECTED]):
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.
