Comments 8
Указания версий тестируемых библиотек конечно не хватает. Вот взять к примеру растовский regex. Всего пару месяцев назад вышла версия 1.9.* (https://github.com/rust-lang/regex/blob/master/CHANGELOG.md#190-2023-07-05), где было много чего переписано, и потому результаты могут значительно отличаться от прошлых версий как в лучшую, так и худшую сторону на разных сценариях.
Спасибо автору за труд.
У меня буквально пару комментариев по поводу тестов, для которых приведены результаты в первых двух таблицах:
Тест на С измеряет "производительность" работы функции
strlen, что IMHO не есть корректно.В тесте на Rust принудительно выключена опция разбора Unicode строк. Для меня лично это выглядит как попытка мухлежа.
Согласен, автор оригинального репозитория этот момент с Rust назвал "оптимизацией" )
Да и вообще, момент с компиляцией регулярок, тоже можно было бы не включать в замеры, если мы измеряем скорость нахождения. Но решил в Бенчмарке#1 оставить всё как было, лишь добавив аналогичный код для Go библиотек.
Если вас не затрунит, не могли бы вы провести модифицированный тест на С с вызовом strlen до clock_gettime.
Как измерялось потребление памяти? Оно включает потребление при компиляции выражений? (В целом, компиляцию и поиск нужно всегда мерить отдельно, потому что где компилируют на каждый поиск, там производительность явно не важна.) Числа не выглядят реалистичным потреблением со стороны именно библиотек, про вызов из Go не могу ничего сказать. Например, Hyperscan во время поиска не выделяет память, а принимает предварительно выделенный блок (scratch) фиксированного размера, который зависит только от базы правил. Но FindAllIndex(), которая используется в замерах, создает scratch при каждом вызове, что совершенно неадекватно реальным сценариям.
Лучший regexp для Go. Benchmark c другими ЯП. Сравнение библиотек