Есть ли какой-либо механизм регулярного выражения, который делает Своевременную компиляцию? [закрытый]
Бобовое соглашение состоит в том, чтобы записать код как это:
private int foo;
public int getFoo() {
return foo;
}
public void setFoo(int newFoo) {
foo = newFoo;
}
На некоторых из других языков на JVM, например, Groovy, Вы получаете переопределяемые свойства, подобные C#, например,
int foo
, к которому получают доступ с простым .foo и усиливает значение по умолчанию getFoo и setFoo реализации, которые можно переопределить по мере необходимости.
8 ответов
Единственный известный мне механизм регулярных выражений, который может компилировать регулярные выражения в исполняемый код, - это тот, который есть в .NET, когда вы передать RegexOptions.Compiled. Это приводит к тому, что класс Regex генерирует MSIL, который затем может быть JITted, как и любой другой код .NET.
Делает ли это механизм регулярных выражений .NET быстрее других - это совершенно другой вопрос. При поиске и замене с использованием относительно простых регулярных выражений в больших наборах данных обработка строк становится гораздо более важной. Строки .NET неизменяемы, поэтому многое будет зависеть от того, сколько раз строку нужно перераспределить.
Ручное кодирование операции всегда будет быстрее, потому что код не эквивалентен. Код регулярного выражения поддерживает определенную информацию о совпадении регулярного выражения и группах захвата, которых нет в вашем коде. В большинстве ситуаций дополнительное время, которое вы тратите на ручное кодирование поиска и замены вместо использования регулярного выражения, не стоит усилий, особенно если вы учитываете, что переключение на другое регулярное выражение тривиально, когда ваши требования меняются, при переписывании поиск и замена с использованием процедурного кода занимает гораздо больше времени.
По моему опыту, PCRE - одна из самых быстрых движков регулярных выражений. Однако в нем нет готовой функции поиска и замены.
В большинстве ситуаций дополнительное время, которое вы тратите на ручное кодирование поиска и замены вместо использования регулярного выражения, не стоит усилий, особенно если вы учитываете, что переключение на другое регулярное выражение тривиально, когда ваши требования меняются, при переписывании поиск и замена с использованием процедурного кода занимает гораздо больше времени.По моему опыту, PCRE - одна из самых быстрых движков регулярных выражений. Однако в нем нет готовой функции поиска и замены.
В большинстве ситуаций дополнительное время, которое вы тратите на ручное кодирование поиска и замены вместо использования регулярного выражения, не стоит усилий, особенно если вы учитываете, что переключение на другое регулярное выражение тривиально, когда ваши требования меняются, при переписывании поиск и замена с использованием процедурного кода занимает гораздо больше времени.По моему опыту, PCRE - одна из самых быстрых движков регулярных выражений. Однако в нем нет готовой функции поиска и замены.
Я не эксперт по Python, но вы можете попробовать Psycho:
Я не вижу этого в вашем вопросе, поэтому я спрашиваю: вы тестировали предварительно скомпилированные регулярные выражения, например, «re.compile (pattern)» ??
Поскольку скомпилированные регулярные выражения должны быть Быстрее. Хорошо, это не JIT, но в большинстве случаев вам подходят просто предварительно скомпилированные!
См. Здесь:
Другая идея: Когда у вас есть библиотека (на C), которая является более оптимальной, чем модуль регулярных выражений Python или которая выполняет своевременную компиляцию регулярных выражений, вы можете написать свой собственный модуль регулярных выражений для python, который просто обертывает вашу C-библиотеку.
Это, конечно, немного больше работы и рекомендуется только тогда, когда вам действительно, действительно нужна скорость.
Вы также можете попробовать Cython (лично я еще не использовал его, но звучит неплохо)
Насколько я понимаю теперь вашу проблему, окружение Python - это не ваша проблема (поэтому я сомневаюсь, что psyco поможет) - также подготовка регулярного выражения - не ваша проблема, но сам пробег должен быть максимальным. Это, конечно, зависит от библиотеки, которую вы используете, и от того, насколько хорошо она может обрабатывать большие строки. Я бы подумал,
Механизм регулярных выражений в Firefox компилирует некоторые (не все!) Регулярные выражения в машинный код. Думаю, Safari и Chrome тоже.
Итак, если я вас правильно понимаю, вы используете язык программирования, который default не выполняет своевременную компиляцию, и теперь вы ищете библиотеку регулярных выражений, которая делает именно это?
Я думаю, вам следует скомпилировать весь свой код Python в двоичный файл, используя, например, Psyco
http: // www .devshed.com / c / a / Python / How-Python-Runs-Programs / 4 /
также обсуждается здесь:
Возможно ли скомпилировать Python в машинный код?
и здесь:
Можно ли скомпилировать Python изначально (за пределами байтового кода pyc)?
Если эти решения либо не работают, либо все еще работают недостаточно быстро, и если вы абсолютно хотите написать остальную часть своего приложения на python, есть библиотека boost python c ++:
http://www.boost.org/doc/libs/1_41_0/libs/python/doc /index.html
Библиотека boost.python обеспечивает полную совместимость между Python и C ++. Затем вы можете использовать средство сопоставления регулярных выражений C ++ boost.regex:
http://www.boost.org/doc/libs/1_41_0/libs/regex/doc/html/index.html
Я могу ошибаться, но я считаю, что модуль регулярных выражений Python находится на C, поэтому любое предложение по компиляции Python (например, с использованием Psycho) не будет иметь большого значения --- что вы на самом деле сравнение - это производительность одной библиотеки регулярных выражений C (Python) с другой (какой бы библиотекой вы ни пользовались).
В сообщении ACM в 1968 году Томпсон опубликовал статью, в которой описывался рабочий JIT-компилятор для регулярных выражений в коде IBM 7094. Я не знаю, на каком языке (а) он говорил; Фортран или LISP были бы очевидными подозреваемыми, причем LISP был бы особенно подозрительным, поскольку он уже имел JIT-компиляцию.