что затем после pyparsing?
Мне разработали огромную грамматику для pyparsing как часть большого, чистого приложения Python. Я достиг предела тонкой настройки производительности, и я в точке, где убывающая доходность заставляет меня начать смотреть в другом месте. Да, я думаю, что знаю большинство подсказок и приемов, и я представил свою грамматику и свое приложение для чистки.
Что дальше?
Я надеюсь найти синтаксический анализатор, который дает мне ту же удобочитаемость, удобство использования (я использую много расширенных функций pyparsing, таких как действия синтаксического анализа для запуска обработки сообщения входа, который анализируется), и интеграция Python, но в 10× производительность.
Я люблю факт, грамматикой является чистый Python.
Все мои базисные блоки являются регулярными выражениями, так многократное использование их было бы хорошо.
Я знаю, что у меня не может быть всего так, что я готов разочароваться в некоторых функциях, которые я должен сегодня получить к требуемому 10× производительность.
Куда я иду отсюда?
4 ответа
Похоже, что разработчики pyparsing предвидели вашу проблему. Из https://github.com/pyparsing/pyparsing/blob/master/HowToUsePyparsing.rst :
Производительность
pyparsingможет быть медленной для сложных грамматик и/или больших входных строк. Пакетpsycoможет быть использован для повышения скорости работы модуляpyparsingбез изменений в грамматике или логике программы - наблюдаемые улучшения были в диапазоне 20-50%.
Однако, как отметил Vangel в комментариях ниже, psyco является устаревшим проектом по состоянию на март 2012 года. Его преемником является проект PyPy, который исходит из того же базового подхода к производительности: использование JIT компилятора нативного кода вместо интерпретатора байткода. Вы должны быть в состоянии достичь аналогичного или большего прироста с PyPy, если переключение реализаций Python будет работать на вас.
Если вы действительно демон скорости, но хотите сохранить некоторую разборчивость и декларативный синтаксис, я бы предложил взглянуть на ANTLR. Возможно, не на бэкенд, генерирующий Python; я скептически отношусь к тому, что он достаточно зрелый и высокопроизводительный для ваших нужд. Я говорю о товаре: бэкенд на языке Си, с которого все началось.
Оберните модуль расширения Python C вокруг точки входа в синтаксический анализатор и разверните его.
Сказав это, вы от многого откажетесь при таком переходе: практически любой Python, который вы хотите сделать в своем парсере, придется делать через C API (что не совсем красиво). Кроме того, вам придется привыкать к совершенно разным способам выполнения задач. У ANTLR есть свои прелести, но он не основан на комбинаторах, поэтому между вашей грамматикой и языком нет той простой и плавной связи, которая есть в парсинге. Кроме того, это собственный DSL, такой же, как lex/yacc, который может быть кривой обучения - но, поскольку он основан на LL, вам, вероятно, будет легче адаптировать его к своим потребностям.
Невозможно узнать, какую выгоду вы получите, не просто протестировав ее, но вполне возможно, что вы можете получить 10-кратную выгоду, просто используя Unladen Swallow , если ваш процесс долгий. - бегущие и повторяющиеся. (Кроме того, если у вас есть много вещей для синтаксического анализа, и вы обычно запускаете новый интерпретатор для каждого из них, Unladen Swallow становится быстрее - до определенной степени - чем дольше вы запускаете свой процесс, поэтому, хотя синтаксический анализ одного ввода может не дать большого выигрыша, вы можете получить значительный выигрыш на 2-м и 3-м входах в одном и том же процессе).
(Примечание: извлеките последнюю версию SVN - вы получите гораздо лучшую производительность, чем последний tarball)
Переключитесь на сгенерированный синтаксический анализатор C / C ++ (используя ANTLR, flex / bison и т. Д.). Если вы можете отложить все правила действий до тех пор, пока вы не закончите синтаксический анализ, вы сможете создать AST с тривиальным кодом, а затем передать его обратно в свой код Python через что-то вроде SWIG и обработать его с помощью ваши текущие правила действий. OTOH, для того, чтобы дать вам прирост скорости, синтаксический анализ должен быть тяжелой работой. Если ваши правила действий требуют больших затрат, это ничего не даст вам, если вы не напишете свои правила действий на C (но вам, возможно, придется сделать это в любом случае, чтобы не платить за любое несоответствие импеданса, которое вы получаете между кодом python и C). .
Если вам действительно нужна производительность для больших грамматик, обратите внимание на SimpleParse (который сам полагается на mxTextTools, расширение C). Однако знайте, что за это приходится платить тем, что она более загадочна и требует от вас хорошего знания EBNF.
Это определенно не более питонический путь, и для использования SimpleParse вам придется начать все сначала с грамматики EBNF.