On Sun, Nov 2, 2008 at 4:43 PM, Mark Miller <[EMAIL PROTECTED]> wrote: > Single processor pentium 4? Shouldn't someone benchmark this with tech from > this century:) you know some comps are not room size now right?
:-P I'm not sure the benchmarks are good enough to draw any useful conclusions, other than FastLRUCache is always a win (even single threaded) when the hit rate of the cache is high (and that's why I've only switched the default on the filter cache). The queryCache and documentCache typically have lower hit rates - but I think someone will need to try out both with Solr (not a micro-benchmark) to tell if it will be a net win for those. -Yonik > 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. >> >
