right Mark, Single proc machines are very rare in production
nowadays.Even laptops come w/ multiple cores


On Mon, Nov 3, 2008 at 2:13 AM, 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?
>
> 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.
>>
>



-- 
--Noble Paul

Reply via email to