lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: lucene 2.9.0RC4 slower than 2.4.1?
Date Wed, 16 Sep 2009 16:44:34 GMT
I agree - best to find the cause before making a decision. There are
enough smart people in the wings, I can't imagine this should take us
that long. We have solved a good chunk of it already, and have only just
begun chunk two.

-- 
- Mark

http://www.lucidimagination.com



Thomas Becker wrote:
> I suggest to find the root cause and then decide about the release. Tomorrow I
> will spent the whole working day on the issue if no prio1 pops up.
>
> Sadly I've to leave early today, since I'm moving to a new flat... :(
>
> Uwe Schindler wrote:
>   
>> How should we proceed? Stop the final artifact build and voting or proceed
>> with the release of 2.9? We waited so long and for most people it is faster
>> than slower!
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>
>>     
>>> -----Original Message-----
>>> From: Mark Miller [mailto:markrmiller@gmail.com]
>>> Sent: Wednesday, September 16, 2009 6:23 PM
>>> To: java-user@lucene.apache.org
>>> Subject: Re: lucene 2.9.0RC4 slower than 2.4.1?
>>>
>>> bq. I'll do some profiling now again and let you know the results.
>>>
>>> Great - it will be interesting to see the results. My guess, based on
>>> the 2.9 new api profiling, is that your queries may not be agreeing with
>>> some of the changes somehow. Along with the profiling, can you fill us
>>> in on the query types you are using as well? (eg qualities)
>>>
>>> And grab invocations if its possible.
>>>
>>> --
>>> - Mark
>>>
>>> http://www.lucidimagination.com
>>>
>>>
>>>
>>> Thomas Becker wrote:
>>>       
>>>> Tests run on tmpfs:
>>>> config: impl=SeparateFile serial=false nThreads=4 iterations=100
>>>>         
>>> bufsize=1024
>>>       
>>>> poolsize=2 filelen=18920301
>>>> answer=850258539, ms=8090, MB/sec=935.4907787391842
>>>> config: impl=ChannelFile serial=false nThreads=4 iterations=100
>>>>         
>>> bufsize=1024
>>>       
>>>> poolsize=2 filelen=18920301
>>>> answer=850258903, ms=39444, MB/sec=191.8700030422878
>>>> config: impl=ChannelPread serial=false nThreads=4 iterations=100
>>>>         
>>> bufsize=1024
>>>       
>>>> poolsize=2 filelen=18920301
>>>> answer=850258903, ms=8504, MB/sec=889.9483066792098
>>>> config: impl=PooledPread serial=false nThreads=4 iterations=100
>>>>         
>>> bufsize=1024
>>>       
>>>> poolsize=2 filelen=18920301
>>>> answer=850258903, ms=9585, MB/sec=789.5795931142409
>>>>
>>>> I did run some tests now with SimpleFSDirectory and MMapDirectory. Both
>>>>         
>>> are
>>>       
>>>> faster than NIOFS and the response times improved. But it's still slower
>>>>         
>>> than 2.4.
>>>       
>>>> I'll do some profiling now again and let you know the results.
>>>>
>>>> Thanks again for all the great support to all who've answered.
>>>>
>>>>
>>>> Mark Miller wrote:
>>>>
>>>>         
>>>>> Can you run the following test on your RAMDISK?
>>>>>
>>>>> http://people.apache.org/~markrmiller/FileReadTest.java
>>>>>
>>>>> I've taken it from the following issue (in which NIOFSDirectory was
>>>>> developed):
>>>>> https://issues.apache.org/jira/browse/LUCENE-753
>>>>>
>>>>>
>>>>>           
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>       
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
>>     
>
>   


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


Mime
View raw message