У меня горит от регулярных выражений. Нет, не от них самих, с ними и так всё понятно (там фундаментально обречено всё на провал) и в какой-то степени плохо, но что мы имеем сейчас на рынке:
1. std::regex, ага, это даже близко не то, что нам хочется, в 10 раз медленнее регулярных выражений в Python
2. PCRE, честно, я не любитель регулярных выражений, которые не применяют никакой фильтрации. Плюс нет никакой защиты от ReDoS, экспоненциальное разрастание регулярных выражений -- проблема на скейле и с безопасностью
3. https://docs.rs/regex/latest/regex/, нет, извините меня любители Раста, я их попробовал и нет, ещё раз нет.
4. Compile time regular expressions. Идея очень хорошая и делает отличный разработчик, но увы, время компиляции тоже не резиновое + сложно тестировать, скажем, я находил баги, но проверял 100 регекспов в час.
5. boost::regex, уже лучше с точки зрения перформанса, но опять же, тонна синтаксисов и никакой настройки, например, хочется лимитировать количество памяти и искать по множеству регекспов
6. RE2. В данном случае запрет синтаксиса так, чтобы ДКА (детерминированный конечный автомат) не разрастался экспоненциально, привел к избеганию огромного количества проблем, слава богу Google додумался сделать это давным давно. Есть много настроек, например, лимитировать количество используемой памяти, а также можно программно получить доступ к частям ДКА. С точки зрения usability прекрасно. Но опять же, мало оптимизаций, никак не оптимизируются множество regexp, практически никакой фильтрации. Сделано добротно, протестировано очень хорошо. Увы, медленно, нет streaming мода.
7. Hyperscan. Мой любиый по перформансу, и я о нём писал несколько раз в канале. Сверхбыстрый, очень много SIMD, очень много настроек, поиск по многим регулярным выражениям, поиск по булевым деревьям: можно сделать
8. Vectorscan. Форк из hyperscan, который приносит мультиплатформенность. Только каким-то, блин, хреном, автор решил переписать самые крутые куски кода на портативный SIMD. Я вчера решил попробовать. Упали по санитайзерам сразу, с грохотом. Учитывая, что делает это один человек, вряд ли они пофиксятся хорошо. Также команда hyperscan ответила мне вчера вот чем
1. std::regex, ага, это даже близко не то, что нам хочется, в 10 раз медленнее регулярных выражений в Python
2. PCRE, честно, я не любитель регулярных выражений, которые не применяют никакой фильтрации. Плюс нет никакой защиты от ReDoS, экспоненциальное разрастание регулярных выражений -- проблема на скейле и с безопасностью
3. https://docs.rs/regex/latest/regex/, нет, извините меня любители Раста, я их попробовал и нет, ещё раз нет.
4. Compile time regular expressions. Идея очень хорошая и делает отличный разработчик, но увы, время компиляции тоже не резиновое + сложно тестировать, скажем, я находил баги, но проверял 100 регекспов в час.
5. boost::regex, уже лучше с точки зрения перформанса, но опять же, тонна синтаксисов и никакой настройки, например, хочется лимитировать количество памяти и искать по множеству регекспов
6. RE2. В данном случае запрет синтаксиса так, чтобы ДКА (детерминированный конечный автомат) не разрастался экспоненциально, привел к избеганию огромного количества проблем, слава богу Google додумался сделать это давным давно. Есть много настроек, например, лимитировать количество используемой памяти, а также можно программно получить доступ к частям ДКА. С точки зрения usability прекрасно. Но опять же, мало оптимизаций, никак не оптимизируются множество regexp, практически никакой фильтрации. Сделано добротно, протестировано очень хорошо. Увы, медленно, нет streaming мода.
7. Hyperscan. Мой любиый по перформансу, и я о нём писал несколько раз в канале. Сверхбыстрый, очень много SIMD, очень много настроек, поиск по многим регулярным выражениям, поиск по булевым деревьям: можно сделать
regexp1 & regexp2 & !(regexp3 | regexp 4). С точки зрения перформанса просто блаженство. Но опять же, нет защиты от ReDoS (экспоненциальное разрастание), Intel забросила поддержку из-за того, что Intel просто разрушила всю команду единственного достойного open source продукта от Intel. Я вчера разговаривал с автором статьи hyperscan, и вот что мне ответили:Geoff: Anyhow, I'm definitely concerned that Hyperscan issues - that look legit to a first glance from me - are being dropped on the table. The thing people outside of Intel need to figure out is how people like me have to sell HS within Intel. If there's no particular commercial reason for Intel to support it they won't. For a long time we were in the position of unquestioned superiority of cores ergo who cares if there's a port to ARM or an AMD benchmark? Now it's not as simple - although I'm long-term bullish Intel. But I'm not too happy with nerds shouting at us on Hacker News who seem to think that Intel is obligated to run a huge, expensive and complicated bit of OSS out of kindness. They've nuked the team before (the original Sydney team) and could nuke it again.Мои баги с корректностью не пофиксили спустя год (пруф1, пруф2, пруф3). Патчи для ARM и других платформ отклоняются. Репозиторий более мёртв, чем жив.
8. Vectorscan. Форк из hyperscan, который приносит мультиплатформенность. Только каким-то, блин, хреном, автор решил переписать самые крутые куски кода на портативный SIMD. Я вчера решил попробовать. Упали по санитайзерам сразу, с грохотом. Учитывая, что делает это один человек, вряд ли они пофиксятся хорошо. Также команда hyperscan ответила мне вчера вот чем
Geoff: There's a big internal dialogue here about Hyperscan and further open source work due to both Vectorscan and, frankly, the fact that AMD is "more than adequate" in the server space. I want to keep moving the project forward but it's complicated. It's *not dead* by ay stretch of the imagination.
btw Vectorscan doesn't pass all our tests when we ported them across. That was my chief irritation with Vectorscan (aside from the low quality).