Нечеткий поиск решил сделать на этой компоненте, лучшего вроде ничего не нашел. Загружаю прайс-листы поставщиков.
Как у этой компоненты с производительностью? Посмотрел в типовых, ей на вход подается строка со ВСЕМИ наименованиями номенклатуры. Это же какая громадная строка может быть? Сколько времени она её будет переваривать?

Кто работал с библиотеками такого типа (все они устроены одинаково, думаю) как у них с производительностью? Что можно предпринять, чтобы повысить скорость?

Как сократить количество подаваемых на вход данных?

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

(2) Смотрел. Полнотекстовый поиск к задаче нечеткого поиска имеет отдаленное отношение. Для задачи загрузки прайсов - не подходит.
FuzzySearch тоже используется в типовых для поиска дублей в справочниках.

(0) Я работал, с производительностью примерно у всех одинаково средне-хреново.
Предпринять чтобы повысить скорость можно предварительную обработку своей номенклатуры (которая обычно постоянная).

Есть такой хитрый "Charikar algoritm (simhash)"
https://en.wikipedia.org/wiki/SimHash

Ну и хорошие результаты по скорости у "N-gram"

(4)+ Суть "ускорения" в чем, вместо того чтобы каждый раз подавать на вход алгоритма пару строк (наша номенклатура и чужая номенклатура).

Подают сразу готовый предобработанный список нашей (по сути хитрый хеш) и одну чужую номенклатуру - в результате оно отрабатывает моментально относительно перебора в цикле для каждой пары наша-чужая.

(5)+ Чуть описания simhash на русском
https://habr.com/company/superjob/blog/325014/
Тут пример для текстов, но как понимаем текст это просто длинная строка.

Для еще большего ускорения реальной работы можно заюзать GPU на OpenCL или CUDA.

(5) Фигасе. Это нужно готовую dll иметь для такого алгоритма, самому не написать.

(7) Ну я когда то https://ru.wikipedia.org/wiki/Расстояние_Левенштейна по алгоритму Вагнера-Фишера наваял еще на 1С77 и оно вполне себе работало и достаточно шустро ))

(8) Понятно, пойду кэшированием займусь..

(9) Тут не кэширование а хеширование.
У похожих строк будут похожие хеши, при правильно выбранной хеш-функции.

(10) Да это понятно. Я ходу пока хотя бы данные подготовить и хранить их в переменно, чтобы каждый раз справочник номенклатуры не перебирать.

Кто знает, что будет, если я очень очень очень большую строку засуну в реквизит внешней обработки?

Я упомянутую в ноль активно использовал. Куча наработок, работало в пару фирм успешно, на лекарствах, на бытовой технике, на игрушках, на чехлах для телефонов. Наработана методика по построению бизнеспроцесса обработки прайсов, их загрузки, привязки, выявления новинок. Базовая концепция чисто техническая как в (5) примерно, основное время жрет построение хеша.
Пример простенького использования смотри на ИСе у меня в профиле, искать можно по
Удар По Бездуховности

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

Стандартная StrMatch.dll штука отличная, но вот когда требуется сравнивать пару списков, причем один на 9к (наши клиенты) а другой http://www.fedsfm.ru/special/documents/terrorists-catalog-portal-act

То оно все очень и очень печально ((

(13) Это понятно, в УТ11 есть спец регистр для привязок

По сути все выливается примерно в такую схему: замускаешь прайс  на вход, система молотит и автопривязывает все по определенному порогу схожести, все что ниже остаётся непривязанным.
Потом садятся операторы и быстрым темпом хренячат аудит сделанных привязок. То что привязалось с высоким процентом схожести почти все подтверждается привязка оператором, в чем он сомневается - передаётся на обработку более квалифицировпнному оператору. Также оператор может в этом процессе ликвидировать сделанную автопривязку. И это тоже пойдёт на следующий уровень обработки.
Здесь главное сделать удобный инструментарий для операторов. И организовать КОНВЕЕРНЫЙ принцип обработки. Не надо одному оператору и валидировать привязки и тут же перепривчзывать неверные, это не продуктивно.
Таким образом прайсы обрабатываются с высокой степень точности за приемлемое время. В том числе и мусорные ненормализовпнные прайсы, которыми оперируют всякие лавочники и один из которых я как-то мане подсунул - на котором его загрузка благополучно ничего вменяемого не смогла сделать.

(14) у меня более менее нормально отрабатывали и на своём справочнике в районе 15к и прайсы в районе 10к.
Не мгновенно конечно , но вполне нормально в рамках установленных регламентов

(15) не знаю что там в этом регистре привязки в ут11 есть, но в тисе где аналогичное тоже есть - такой регистр пришлось расширять допреквизитами

При построении хеша наших номенклатур  при подготовительной работе следует исключить все не фонетические незгачимые символы, пробелы и прочую шнягу. Такие нормализованные наименования можно считать заранее и хранить в базе для быстрого построения хеша.

Спасибо, впечатляет :)

Кроме регистра привязок который есть штатно был сделан регистр типа слепок Прайса в который как раз и грузились прайсы перед собственно сравнением. Все загружаемые прайсы приводились к нормализованному  виду обработкой плагинами, практически на каждый Прайс свой плагин - это исключительно для единообразия процедур загрузки сравнения и привязки - можно и без этого обойтись но если автор будет делать более менее нормально то придёт к этому.

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

Нормализация Прайса включала в тч и чисто эмпирические исправила типа
0.4кг превращались в 400г

У вас там супер система, Маня кусает локти от зависти :)

(23) не, ничего особенного.
вдобавок это все работало по принципу работает и ок, оптимизации по быстродействию не проводилось.
и было это сделано давно в 2003-2007гг.

В дальнейших проектах/разработках по сути части только использовались.

еще весом чисел надо поиграться, в зависимости от прайсов.