Тесты библиотеки регулярных выражений Java — 2015

Пытаясь вывести Java на первое место в конкурсе regexdna для The Computer Language Benchmarks Game, я исследовал производительность библиотек регулярных выражений для Java. Самым последним веб-сайтом, который я смог найти, был tusker.org с 2010 года. Поэтому я решил переделать тесты с использованием Java Microbenchmarking Harness и опубликовать результаты (предупреждение спойлера: я получил Java на # 1 с помощью некоторых неортодоксальных решений).

TL; DR : регулярные выражения хороши для специальных запросов, но если у вас есть что-то чувствительное к производительности, вы должны вручную написать свое решение (это не значит, что вы должны начинать с абсолютного нуля — например, в библиотеке Google Guava некоторые полезные утилиты, которые могут помочь в написании читабельного, но также и производительного кода).

А теперь для некоторых графиков, суммирующих производительность — тест проводился на 64-битной машине Ubuntu 15.10 с OpenJDK 1.8.0_66:

наблюдения

• не существует «стандарта» для регулярных выражений, поэтому разные библиотеки могут вести себя по-разному, если им дано определенное регулярное выражение и определенная строка для сопоставления, т.е. один может сказать, что это соответствует, но другой может сказать, что это не так. Например, хотя я использовал очень ограниченный набор тестовых случаев (5 регулярных выражений, проверенных по 6 строкам), только двум библиотекам удалось сопоставить или не сопоставить их все правильно (одна из них — java.util.Pattern).
• вероятно, потребуется несколько попыток, чтобы получить правильное регулярное выражение (такие инструменты, как regexpal или Regex Coach , очень полезны для экспериментов)
• Производительность регулярного выражения трудно предсказать (и иногда она может иметь экспоненциальную сложность в зависимости от длины ввода ) — из-за этого вам нужно дважды подумать, если вы принимаете регулярное выражение от произвольных пользователей в Интернете (например, поисковая система, которая позволит поиск по регулярным выражениям, например)
• похоже, что ни одна из библиотек больше не находится в активной разработке (на самом деле, многие из исходного списка на tusker.org сейчас недоступны), и многие из них работают медленнее, чем встроенный juPattern , так что если вы используете регулярные выражения, которые должны вероятно, будет первым выбором.
• При этом производительность как оборудования, так и JVM была значительной, поэтому, если вы используете одну из этих библиотек, она обычно работает на порядок быстрее, чем пять лет назад. Поэтому нет необходимости быстро заменять рабочий код (если ваш профилировщик не скажет, что это проблема :-))
• следите за вызовами String.split в циклах. Хотя он имеет некоторую оптимизацию для конкретных случаев (например, регулярные выражения с одним символом), вы должны почти всегда:
  • посмотрите, можете ли вы использовать что-то вроде Splitter от Google Guava
  • если вам нужно регулярное выражение, хотя бы предварительно скомпилируйте его вне цикла
• Два сюрприза были dk.brics.automaton, которые превзошли все остальные на несколько порядков:
  • последний релиз был в 2011 году и, кажется, больше академический проект
  • он не поддерживает тот же синтаксис, что и java.util.Pattern (но не выдает предупреждение, если вы пытаетесь использовать juPattern — он просто не будет соответствовать строкам, которые, по вашему мнению, должны)
  • не имеет API так же удобно, как juPattern (например, отсутствуют замены)
• Другим сюрпризом был kmy.regex.util.Regex , который — хотя и не обновлялся с 2000 года — превзошел java.util.Pattern и прошел все тесты (которых, по общему признанию , было немного ).

Полный список используемых библиотек:

Если вы хотите перезапустить тесты, проверьте исходный код и запустите его следующим образом:

И, наконец, как насчет задачи regexdna для игры The Computer Language Benchmarks Game ? Я получил Java на # 1, используя битовые операции, чтобы проверить блоки по 8 байт, если они являются потенциальными совпадениями, и только затем проверить их на соответствие регулярным выражениям. Как я уже говорил ранее: если вам нужна производительность, вам нужно написать свои собственные парсеры.