Tiene usted razón de que el n. ° 3 será más rápido, pero no creo que sea por la puntuación. Hay una manera mucho más rápida, salta al final si no te importa el razonamiento detrás de esto.
La pérdida de rendimiento de # 1 proviene del hecho de que el recopilador de TopDocs mantendrá los documentos en una cola de prioridad, lo que significa que perderá algo de tiempo clasificándolos por puntaje. (También consumirá algo de memoria, pero como está almacenando solo un montón de pares int + float, probablemente sea bastante mínimo.)
¿Por qué Lucene no proporciona esto de la caja ?: en general no quiero encontrar todos los resultados Es por eso que cuando buscas, dices que solo encuentras los primeros n resultados. Hay strong theoretical reasons para esto. Incluso Google dice "Mostrando 25 de sobre n results."
Así que mi consejo para usted es el siguiente: si tiene una cantidad razonable de resultados, entonces usar TopDocs.totalHits no será tan malo para el rendimiento. Si el método totalHits le da problemas, no creo que un recopilador personalizado sea mucho mejor. (TopDocs.totalHits se ejecutará en n log n time, y el recopilador personalizado será lineal. Dependiendo de su configuración, el coeficiente log n puede ser relevante, o no).
Por lo tanto, si necesita absolutamente esta funcionalidad, y TopDocs.totalHits es demasiado lenta, recomendaría mirar la frecuencia del documento de los términos de búsqueda. Podría suponer que la frecuencia es independiente (entonces p (A y B) = p (A) * p (B)) y hacer una buena suposición a partir de ahí. Será muy rápido, porque es solo una búsqueda de tiempo constante para cada término.
Gracias por eso. Parece que estará en una próxima versión de Lucene? – npellow
sí, esta es la rama para las próximas versiones 3.x (el próximo objetivo es 3.1) –
Ese enlace devuelve un 404 –