Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <762DAB9B-4B30-4B6C-B9D4-1E0101371F47@apache.org>
From: Grant Ingersoll <gsingers@apache.org>
To: java-dev@lucene.apache.org
In-Reply-To: <4A81C49E.4000407@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: who clears attributes?
Date: Tue, 11 Aug 2009 16:56:50 -0400
References: <c68e39170908100901m35f325fcm10fa5225efb0bac9@mail.gmail.com>
 <c68e39170908100955y22ee8607y553268eb452b96e7@mail.gmail.com>
 <23A9FD4876BD40B3BE312126E12B3E18@VEGA>
 <c68e39170908101042j769c7134j7f652725abd1702a@mail.gmail.com>
 <D47E9BB6AC364B36A15D1EDA7470228E@VEGA>
 <59b3eb370908101100xda2d85ag222599ad11a1f1ba@mail.gmail.com>
 <A4661DD1-F219-4F57-9D11-32694F1C191B@apache.org>
 <345ECC25630C46B8B55AED45F8B2C691@VEGA>
 <4266B483-E969-44B0-90EC-810132D5A4B2@apache.org>
 <B1F0812104E0461AAA3C2B808C8C9028@VEGA>
 <786fde50908101412y4f52ffdcp71e7482c10550082@mail.gmail.com>
 <E60B885E-7AE4-4BC9-A3D9-2B0EDC2BCD7D@apache.org>
 <4A809F06.3000508@gmail.com>
 <E1070CAA-A46F-4C66-8A01-3A16784AB8D8@apache.org>
 <4A80CE34.8030208@gmail.com> <4A812BC7.7000408@gmail.com>
 <9FAFA8FA-D5BE-45F1-AD53-9BD6C2FEE5C4@apache.org>
 <4A81C49E.4000407@gmail.com>


On Aug 11, 2009, at 3:21 PM, Michael Busch wrote:

> On 8/11/09 4:13 AM, Grant Ingersoll wrote:
>>
>> On Aug 11, 2009, at 4:28 AM, Michael Busch wrote:
>>
>>>
>>>> I'm not just responding to just you there, but more to the  
>>>> growing pack of those speaking against the new API. I don't see  
>>>> specific issues being brought up - the only issues I have seen  
>>>> brought up have been addressed in JIRA issues that have received  
>>>> no comments indicating the fix was not good enough. So we are  
>>>> seeing a lot of general complaints, but specific complaints have  
>>>> been addressed as far as I can tell.
>>>>
>>> Thanks Mark. Yeah, I'm really not sure what actually the problem  
>>> here is now. There was a performance test in Solr that apparently  
>>> ran much slower after upgrading to the new Lucene jar. This test  
>>> is testing a rather uncommon scenario: very very short documents.
>>
>> That is not an uncommon scenario.  Solr has very, very short fields  
>> _ALL THE TIME_.
>>
>
> I meant that having documents that only contain very short fields is  
> not as common as having docs with a decent amount of text.  Maybe  
> I'm wrong - in either case I didn't try to say it's not an important  
> use case. I think it is important to have good performance here  
> too.  The point I was trying to make was that we tested performance  
> more thoroughly for the case we thought would be more common.

FWIW, I think the most common scenario is: one or two large fields and  
several (usually in the range of 5-10, but have seen cases with many)  
small fields, at least that has been my experience.  Some of the small  
fields require analysis, some don't.

>
> According to the numbers posted on LUCENE-1796 it now seems like  
> it's fixed - even for documents with only very short fields and no  
> reusable TokenStreams.
>

Very cool.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org