Почему существует значительная разница во времени поиска между lucenenet на c # и lucene на Java, в то время как другие статистические данные примерно сопоставимы?

#java #c# #lucene #lucene.net

#java #c# #lucene #lucene.net

Вопрос:

Я реализовал Lucene POC на Java и dotnet. Статистика примерно сопоставима, за исключением времени поиска (времени, необходимого для получения соответствующих документов). Java-приложение примерно занимает 9-10 секунд, тогда как Dotnet занял 52 минуты. Я проиндексировал 99000 документов, которые состоят из pdf, docs, txt и т.д. Индексация для обоих POCS выполнялась для одних и тех же файлов. Ожидается ли это несоответствие во времени поиска из-за того, что версия Java превосходит или есть какая-то ошибка в моем кодировании для lucenedotnet?

Комментарии:

1. » Почему существует значительная разница во времени поиска между языком бла и языком бла? * — просто это не один и тот же язык, вероятно, оптимизированный по-разному, написанный кто знает, кто знает каким образом

2. Разница в порядках величины не объясняется просто разными языками. Есть кое-что еще, что отличается.

3. Похоже, что для меня есть какая-то ошибка.

4. Может быть, вы хотите спросить здесь github.com/apache/lucenenet/issues

5. Самым простым объяснением было бы то, что Lucene. Сеть глючит, последняя версия все еще находится в бета-версии. Поскольку это порт версии Java, он не должен быть заблокирован, если он менее зрелый и может иметь некоторые проблемы с производительностью. Вы также могли бы выполнить некоторое профилирование, чтобы убедиться, что ваш собственный код не виноват.

Ответ №1:

Эти вопросы также были представлены в качестве проблемы в lucene.СЕТЕВОЙ репозиторий. Для документации здесь, в StackOverflow, о производительности Lucene.NET 4.8 Бета, я процитирую ответ одного разработчика, jeme:

Это, безусловно, звучит чрезмерно подозрительно, у нас есть индекс с более чем миллионом документов, каждый из которых содержит тысячи полей. Если я выполняю бесплатный текстовый поиск (что означает, что он обращается ко всем полям), начинающийся и заканчивающийся шаблоном (например, a), что, вероятно, является наихудшим сценарием, который я могу придумать, это занимает всего ~ 50 секунд, то есть включая загрузку фактических 9 мегабайт данных, которые выдает поиск, и возврат их по проводам. (не совсем удовлетворительно, но, учитывая наказание, которое я только что направил на index wire, это в некоторой степени понятно)…

После дальнейших исследований проблема возникла при использовании версии 3.03 Lucene.NET, а не 4.8 Beta. Неясно, связана ли проблема производительности, на которую ссылается этот разработчик, с Lucene.NET 3.03 исходный код или исходный код конкретной реализации проекта.

Вы можете прочитать больше здесь:https://github.com/apache/lucenenet/issues/333#issuecomment-685039718