Zute

Рейтинг
32
Регистрация
03.01.2004
Как писал Evg
http://aspseek.itmag.ru/filemanager/.
В нем исключены (проверял) смешения файлов от разных версий.
Сообщать о багах, ошибках желательно аналогично на
aspseek.itmag.ru

Эффект тот же, не собирается.

А куда на aspseek.itmag.ru сообщения о багах постить, там ведь только форум ?

Как писал absolut

gmake вместо make

без разницы, эффект тот же...

configure именует себя 2NET v.1.0

по-прежнему не собирается на FreeBSD...

WordNet http://www.cogsci.princeton.edu/~wn/

Есть в портах FreeBSD, используется в kde и koffice - скорее всего есть и в Линуксах.

Как писал Evg
Дело не только в цифре, которая показывается в результатах поиска. Но и во времени обычного отображения страницы.
Если бы при 5 миллионах документов разница была бы 1-2 секунды, то возможно об этом я и не заговорил.
Однако разница была в разы.

На моей базе время, затрачиваемое на построение цитат, обычно больше времени, затрачиваеемого на собственно поиск документов.

А эффект получается таким: dataparksearch сначала строит цитаты для всех выводимых документов, а потом собвенно начинает выводить результаты, aspseek же строит цитату для первого документа, потом выводит кусок страницы с эти результатом, потом начинает строить цитату для второго и т.д. В результате веб-сервер у aspseek начинает раньше отдавать страницу клиенту...

Как писал Vyacheslav Tikhonov

Либо предоставьте ссылки, где мои "заявления" не соответствуют действительности, либо извинитесь. То, что я не люблю поисковиков на СУБД - это факт, однако чтобы говорить об этом подобным образом, нужны убедительные аргументы, которые меня опровергают.
Итак?

Я не хочу вступать с вами в никакие разборки, если вас действительно интересует именно этот вопрос - воспользуйтесь поиском по форуму, - в тех местах, где я счёл нужным сделать, а вас поправил. Могу вам напомнить, что в одном из топиков, вы сами признались, что последний раз смотрели на mnogosearch пару-тройку лет назад, - это уже значительно устаревшая информация, именно не соответсвующая действительности...

Как писал Evg

Если брать 300 т. документов, то по скорости индексации DataparkSearch и ASPseek приблизительно одинаковы с незначительным опережением ASPseek.
При больших объемах разница достаточно заметна даже на глаз, тут я говорю не о секундах (еще раз повторяюсь, к сожалению, под рукой нет точных данных).
Что же касается времени поиска, то чем больше объем «индекса» тем вперед быстрее вырывается ASPseek далее идет DataparkSearch…
Время расчёта релеватности документов входило в сравнение.
У DataparkSearch были убраны те секции, которых нет у ASPseek (кстати, это на мой взгляд один из недостатков данной системы)

Я тестировал DataparkSearch и ASPSeek примерно на одинаковых базах в 300-350 тыс. документов. Скорость индексации действительно была примерно одинаковой с незначительным преимуществом ASPSeek. Но DataparkSearch при это ещё строит матрицу ссылок между документами, чего не делает ASPSeek. Похоже именно из-за это матрицы и начинаются тормоза при большом количестве документов.

По скорости поиска: а как вы её измеряли ? Дело в том, что эти поисковики по-разному считают цифру, которую выводят в качестве времени поиска. ASPSeek выводит время нахождения собственно документов, DataparkSearch плюс к этому еще учитывает время построения цитат по словам из запроса.

Как писал Vyacheslav Tikhonov

Прошу прощения за оффтопик. Zute, судя по всем вашим постам с обязательным упоминанием DataparkSearch, вы его разработчик?

Судя по вашим заявлениям об этих системах (ASPSeek, mnogosearch, dataparksearch), несколько далёких от действительности (ну или от того, что я видел и тестил лично)... :)

Может не будем гадать ? :)

Значительно - это сколько ? И как проводилась проверка, входило ли в сравниваемое время время расчёта релеватности для проиндексированых документов ?

Всего: 218