Почему мое регулярное выражение намного медленнее компилируется, чем интерпретируется?

Question

У меня есть большое и сложное регулярное выражение C#, которое работает нормально при интерпретации, но немного медленнее. Я пытаюсь ускорить это, установив RegexOptions.Compiled, и это, кажется, занимает около 30 секунд в первый раз и сразу после этого. Я пытаюсь это отрицать, сначала компилируя регулярное выражение на сборку, поэтому мое приложение может быть как можно быстрее.

Моя проблема в том, когда сбор задержка происходит, будь то компилируется в приложении:

Regex myComplexRegex = new Regex(regexText, RegexOptions.Compiled); 
MatchCollection matches = myComplexRegex.Matches(searchText); 
foreach (Match match in matches) // <--- when the one-time long delay kicks in 
{ 

} 

или с помощью Regex.CompileToAssembly заранее:

MatchCollection matches = new CompiledAssembly.ComplexRegex().Matches(searchText); 
foreach (Match match in matches) // <--- when the one-time long delay kicks in 
{ 

} 

Это делает компиляции для сборки в основном бесполезно, поскольку я все еще получаю задержку при первом вызове foreach. Я хочу, чтобы вся компиляция была выполнена во время компиляции (при вызове Regex.CompileToAssembly), а не во время выполнения. Где я иду не так?

(Код, который я использую для компиляции сборки, аналогичен http://www.dijksterhuis.org/regular-expressions-advanced/, если это необходимо).

Edit:

Должен ли я использовать new при вызове скомпилированной сборки в new CompiledAssembly.ComplexRegex().Matches(searchText);? Однако он дает ошибку «ссылка на объект».

Update 2

Спасибо за ответы/комментарии. Регулярное выражение, которое я использую, довольно длинное, но в основном прямолинейное, список тысяч слов, каждый из которых разделен символом |. Я не вижу, чтобы это было проблемой возврата. Строка subject может быть длиной всего одна буква, и она все равно может привести к задержке компиляции. Для регулярного выражения RegexOptions.Compiled это займет более 10 секунд, чтобы выполнить, когда регулярное выражение содержит 5000 слов. Для сравнения, не скомпилированная версия регулярного выражения может принимать 30 000 слов и выполнять их практически мгновенно.

После этого много испытаний на это, что я думаю, что я узнал, это:

• Не используйте RegexOptions.Compiled, когда ваше регулярное выражение имеет много альтернатив - это может быть очень медленно, чтобы компиляции.
• .Net будет использовать lazy evaluation for regex, если возможно, и AFAI может видеть, что это также расширяет (по крайней мере до некоторой степени) компиляцию регулярных выражений. Регулярное выражение будет полностью скомпилировано только тогда, когда оно должно быть, и, похоже, не существует способа форсировать компиляцию раньше времени.
• Regex.CompileToAssembly будет намного полезнее, если бы регулярные выражения могли быть полностью скомпилированы, похоже, что они не имеют никакого смысла.

Пожалуйста, исправьте меня, если я ошибаюсь или что-то не хватает!

Answer 1

Попробуйте использовать Regex.CompileToAssembly, а затем ссылку на сборку, чтобы вы могли создавать объекты Regex. RegexOptions.Compiled - это параметр времени выполнения, регулярное выражение все равно будет перекомпилировано каждый раз при запуске приложения.

Answer 2

При использовании RegexOptions.Compiled вы должны обязательно повторно использовать объект Regex. Не похоже, что вы это делаете.

RegexOptions.Compiled является компромиссом. Начальная конструкция Regex будет медленнее, потому что код компилируется «на лету», но каждый матч должен быть быстрее. Если ваше регулярное выражение изменяется во время выполнения, вероятно, не будет пользы от использования RegexOptions.Compiled, хотя это может зависеть от фактического выражения.

Update, в комментариях

Если фактический код выглядит так, как вы в курсе, что вы не принимаете какие-либо преимущества CompileToAssembly, как вы создаете новый, на лету скомпилированные экземпляры Regex каждого время, в течение которого выполняется часть кода. Чтобы воспользоваться преимуществами CompileToAssembly, вам нужно сначала скомпилировать Regex; затем возьмите сгенерированную сборку и укажите ее в своем проекте. Затем вы должны создать экземпляр генерируемых, сильно типизированных типов выражений.

В примере, к которому вы ссылаетесь, он имеет регулярное выражение с именем FindTCPIP, которое скомпилируется в тип с именем FindCTPIP. При этом необходимо использовать, необходимо создать новый экземпляр этого конкретного типа, такие как:

TheRegularExpressions.FindTCPIP MatchTCP = new TheRegularExpressions.FindTCPIP(); 

Answer 3

Весьма вероятно, причиной при исследовании медленно регулярного выражения в том, что она откатывается слишком много. Это решается путем перезаписи регулярного выражения, так что число обратных следов не существует или минимально.

Можете ли вы разместить регулярное выражение и образец ввода там, где он медленный.

Лично мне не нужно было компилировать регулярное выражение, хотя было бы интересно увидеть некоторые фактические цифры о производительности, если вы выбрали этот путь.

Answer 4

Чтобы принудительно инициализировать, вы можете вызвать совпадение с пустой строкой. Кроме того, вы можете использовать ngen для создания собственного образа выражения, чтобы ускорить процесс еще больше. Но, вероятно, самое главное, по сути, так же быстро бросать 30 000 строк. Индексы или инструкции string.Contains или Regex.Match в отношении данного текста, чем компиляция ginormous big expression для сопоставления с одним текстом. Поскольку это требует намного меньше компиляции, джитсинга и т. Д., Поскольку машина состояния намного проще.

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