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.
Cheers,
Grant
>>> [EMAIL PROTECTED] 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.
>>> [EMAIL PROTECTED] 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
scheme?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
