дайте идею чё бы оптимизнуть простого :(

Владимир прав, лучше заранее отсортировать лист и вместо Contains использовать BinarySearch >=0

Ну, я попробую,
Думал regex, но вот шаблон хардкорный будет
Просто все в обычном string хранился )
Придется реально в словарь какой загнать

у чувака сомнения регекс надо или нет, а вы ему про бинарный поиск
ебанарот, в адеквате ваще? %)

Если надо проверить подстроку в середине, то как сортировать?

Не, просто регекс на 30-40 параметров крайне жирный выйдет и медленный, по этому не особо охотно его юзать

прочитает и поймет, делов-то. Надо было еще указать про безусловную linear complexity Contains, отчего его код может легко превратиться в тыкву.

если задача не сводится к Contains, тогда надо применять что-то другое.

какой код? arr.first на 30 элементах?

сделает так в цикле - получит квадратичную сложность

Что может пойти не так?

ты почему-то изначально думаешь что у него там высоконагруженный сервис с миллионом транзакций в секунду
но посмотри на его вопросы - у него не тот случай %)

но да, перечитал его потребности - там список строк, в котором надо искать совпадение. Если совпадение бъется по границе слова и строки реиспользуются, то можно сделать split каждой строки и искать не в строках, а в списках слов

если строки уникальны - надо искать линейно

Хм, столько решений)
А как лучше? Суть такая

У меня выход из консоли не больше 1000 строк

Каждая уникальная
У каждой строки вид
[Param] value
Меняется только value, но частота маленькая, не чаще раза в минуту
А то и вообще в час

Сверхнагрузки нет
Думал, есть просто аналог стримридера, там можно строку просто читать каждую (не нагружая систему файлом в лярд строк сразу), и если есть совпадение нужное, записывать её куда то

А если без файла, я так понимаю, не простого решения вида forearch(...)
if..
....

лучше так как ты сам сможешь написать и понять
а то что эти оптимизаторы понаписали, не принимай близко к сердцу %)
они привыкли что не байтоебил - не мужик!

Понял, спасибо)))

Байтоёбы)) ржу))))