lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Ingersoll" <>
Subject Re: RE : ReSorting
Date Wed, 26 May 2004 13:05:10 GMT
Ran some informal tests.  Eric, you are definitely right, it is faster to search again, assuming
you don't already have an advanced caching system in place.   The other tradeoff to consider
is the size of the sort cache, which the docs say is: 4 * IndexReader.maxDoc() * (# of different
fields actually used to sort).  As for simplicity, Tim's sorting code is the way to go as
it is already native to Lucene, saving developer's from having to write their own.

On a side note, it was a real eye opener to see the value of a tightly written comparator
function in sorting performance.  One should be careful about how they implement a comparator.


>>> 05/25/04 10:58AM >>>
No I am not sorting massive results.  My sort code was put in before the new sorting functionality,
which I haven't looked at yet.  I haven't done any performance comparisons as of yet.  I also
use HitCollector to restrict the number of results retrieved to begin with.  I have been meaning
to look at the new sort code soon.

>>> 05/25/04 10:39AM >>>
On May 25, 2004, at 9:59 AM, Grant Ingersoll wrote:
> I solve this problem by using the HitCollector interface instead of 
> the Hits interface and putting the hit information into my own 
> SearchResult object which is then stuffed into a SortedSet.  I can 
> then easily resort as needed using the standard collection 
> capabilities in Java.
> Using HitCollector is pretty straightforward to implement.

I'm assuming you are not sorting massive amounts of results with this 


To unsubscribe, e-mail: 
For additional commands, e-mail: 

To unsubscribe, e-mail:
For additional commands, e-mail: 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message