RE2 и ускорение regexp

Дык re2 не полноценная (читай ничего нужного не умеет), зачем она тебе?

Так мне скорость нужна ну и память ,а всякие lookahead и ТД не нужно

Сперва дай опредление, что понимаешь под «regexp». Опорные точки https://ru.wikipedia.org/wiki/Регулярные_грамматики и https://ru.wikipedia.org/wiki/Иерархия_Хомского. Расширенные регулярные выражения grep и регуляные выражения perl - это ненастоящие регулярные выражения.

Модуль regexp го.

Судя по синтаксису re2 - это хорошо подсахаренный «настоящий regex», хотя некоторые конструкции уже на грани. Думаю, если не вылезать за возможности «настоящих регулярных» выражений (например группировки, пустые символы), то не вылезет за гарантированную линейую сложность. Зависит от качества реализации re2.

Есть ещё hyperscan, можно прицепить через cgo

Поподробнее ? Есть модуль на go ?

А кстати в поиске что может дать линейную скорость (алгоритм кнута-морриса плата) и есть ли модуль готовый под него?

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

Ок,а как лучше по вашему решить задачу поиска шаблонов в огромном тексте на go?

Понять, ложится ли задача на чистые регулярные выражения. Если да, связаться с авторами re2, узнать как работает. Если это правильный настоящий regex, то поиск будет за линейное время, плюс время компиляции регулярного выражения.

У них на wiki написано:

One of its primary guarantees is that the match time is linear in the length of the input string.

Но ещё и это:

It is not a goal to be faster than all other engines under all circumstances.

Раз они борются с рекурсиями - это ненастоящий регекс. Также это говорит о том, что это совсем не линейное время поиска.

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

А есть ли примеры использования на том же go ?

Я с go вообще не взаимодействовал никак, так что не знаю. Пара биндингов гуглится, но оценить их я никак не смогу.

Кстати походу биндинги под него есть https://github.com/flier/gohs?files=1

А как оно быстрее и лучше чем стандарные решения на pcre ?

Читая документацию могу предположить, что строит недетерминированный КА, а это в общем случае нелинейное время. Зато оптимизации под sse и avx. Хотя, щас вроде никто не строит ДКА, потому что силно ограниченный этот настоящий регекс.

Интересно насколько оно лучше чем стандартный pcre ?

Однозначно быстрее. «Лучше» - это эмоциональная оценка, что не к месту. И да, судя по твоим вопросам, тебе должно быть все равно. Бери стандартный и не парся.

Да вот хотелось бы наиболее оптимальный по скорости , память как я понял не так критична,иначе не началбы тему .

А так решение на стандартных есть .

golang.org/pkg/regexp/
The regexp implementation provided by this package is guaranteed to run in time linear in the size of the input.

у тебя есть проблемы с перфомансом stdlib regex, или ты думаешь что они будут?

lookahead и ТД не нужно

их в go regex и нет

Это понятно , а как оно со скоростью , в этом и весь вопрос ,может задача поиска шаблона многострочного в многострочном много гигайбатном файле или ещё хуже имеет лучшее решение,по части поддержки?

Они будут боюсь,

Они будут боюсь,

проверь, чтобы знать есть ли смысл от дополнительной работы и прибавки стоимости к поддержке. это займет минуту

Я не знаю, что ты там ещё ускорять собрался.

Это (swtch.com) в принципе, то, что используется в стандартной библиотеке.

https://swtch.com/~rsc/regexp/regexp1.html
Я не знаю, что ты там ещё ускорять собрался.

Не помню, вроде в «книге дракона» был алгоритм, как сразу по «настоящему регулярному выражению» построить ДКА. Так, что есть куда ускорять, если именно «настоящие».

А вот нет , или оно уже в стандартной библиотеке https://github.com/samthor/sre2 ?

Хотя да , там уже все зааптимизирована в последних версиях гошки

The regexp implementation provided by this package is guaranteed to run in time linear in the size of the input.

https://golang.org/pkg/regexp/