Вы правы, что №3 будет быстрее, но я не думаю, что это из-за выигрыша.Существует гораздо более быстрый способ, перейдите к основанию, если вас не интересуют причины этого.
Потеря производительности # 1 происходит из-за того, что сборщик TopDocs будет хранить документы в очереди с приоритетами, что означает, что вы потеряете некоторое время, сортируя их по счету.(Вы также израсходуете немного памяти, но, поскольку вы храните только кучу пар int + float, это, вероятно, довольно минимально.)
Почему Lucene не предоставляет это из коробки:Вы обычно не хотите, чтобы найти все результаты.Вот почему при поиске вы говорите, что найдете только самые лучшие n результаты.Для этого есть веских теоретических оснований .Даже Google говорит: «Показано 25 из о n результатов».
Так что мой совет вам следующий: если у вас есть разумное количество результатов, то использование TopDocs.totalHits не будетбыть слишком плохим с точки зрения производительности.Если метод totalHits доставляет вам проблемы, я не думаю, что пользовательский сборщик будет намного лучше.(TopDocs.totalHits будет запущен через n log n раз, а пользовательский сборщик будет линейным. В зависимости от вашей настройки коэффициент log n может быть релевантным или нет.)
Итак, если выэта функциональность абсолютно необходима, а TopDocs.totalHits слишком медленный, я бы порекомендовал посмотреть на частоту поисковых запросов в документе.Вы можете предположить, что частота независима (поэтому p (A и B) = p (A) * p (B)) и сделать довольно хорошее предположение отсюда.Это будет очень быстро, потому что это просто поиск в постоянном времени для каждого термина.