что дальше после разборки?

Question

У меня есть огромная грамматика, разработанная для pyparsing как части большого, чистого Python-приложения.Я достиг предела настройки производительности, и я нахожусь в точке, где убывающая отдача заставляет меня начать искать в другом месте.Да, я думаю, что знаю большинство советов и хитростей, и я описал свою грамматику и свое приложение в пыли.

Что дальше?

Я надеюсь найти синтаксический анализатор, который даст мне такую ​​же читабельность, удобство использования (я использую много расширенных функций pyparsing, таких как parse-actions, чтобы начать постобработку анализируемого ввода) и pythonинтеграция, но при 10 × производительности .

Мне нравится тот факт, что грамматика является чистым Python.

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

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

Куда мне обратиться?отсюда?

Answer 1

Похоже, что пиарсинг предвидел вашу проблему. От https://github.com/pyparsing/pyparsing/blob/master/HowToUsePyparsing.rst:

Производительность pyparsing может быть медленной для сложных грамматик и / или больших строк ввода. Пакет psyco можно использовать для повышения скорости модуля pyparsing без изменений в грамматике или логике программы - наблюдаемые улучшения были в диапазоне 20-50%.

Однако, как отметил Вангель в комментариях ниже, psyco является устаревшим проектом с марта 2012 года. Его преемником является проект PyPy , который начинается с того же базового подхода к производительности: используйте JIT-компилятор с собственным кодом вместо интерпретатора байт-кода. Вы должны быть в состоянии достичь такого же или большего прироста с PyPy, если переключение реализаций Python будет работать для вас.

Если вы действительно демон скорости, но хотите сохранить некоторую разборчивость и декларативный синтаксис, я бы посоветовал взглянуть на ANTLR. Вероятно, не Python-генерирующий бэкэнд; Я скептически отношусь к тому, достаточно ли он зрел или высокопроизводителен для ваших нужд. Я говорю о товаре: бэкэнд C, с которого все началось.

Оберните модуль расширения Python C вокруг точки входа в анализатор и освободите его.

Сказав это, вы многим откажетесь в этом переходе: в основном, любой Python, который вы хотите сделать в вашем парсере, должен выполняться через C API (не совсем красиво). Кроме того, вам придется привыкать к совершенно разным способам ведения дел. У ANTLR есть свои прелести, но он не основан на комбинаторах, поэтому между грамматикой и языком нет простых и плавных отношений, которые есть у pyparsing. Кроме того, это собственный DSL, очень похожий на lex / yacc, который может представить кривую обучения, но, поскольку он основан на LL, вам, вероятно, будет проще адаптироваться к вашим потребностям.

Answer 2

Если вам действительно нужна производительность для больших грамматик, посмотрите не дальше, чем SimpleParse (который сам по себе опирается на mxTextTools, расширение C).Однако, теперь знайте, что это происходит за счет того, что вы должны быть более загадочными и требовать, чтобы вы хорошо разбирались в EBNF .

Это определенно не более Pythonic маршрут, и вам придется начинать все сначала с грамматики EBNF, чтобы использовать SimpleParse.

Answer 3

Переключение на сгенерированный синтаксический анализатор C / C ++ (используя ANTLR, flex / bison и т. Д.).Если вы можете отложить все правила действия до тех пор, пока не закончите синтаксический анализ, вы сможете создать AST с тривиальным кодом, а затем передать его обратно в свой код Python через что-то вроде SWIG и обработать его с помощьюваши текущие правила действий.OTOH, для того, чтобы дать вам повышение скорости, разбор должен быть тяжелым.Если ваши правила действий стоят больших затрат, то это ничего не купит, если вы не напишите свои правила действий также на C (но вам, возможно, придется делать это в любом случае, чтобы не платить за любое несоответствие импеданса, которое вы получаете между кодом Python и C)..

Answer 4

Немного опоздал на вечеринку, но PLY (Python Lex-Yacc) , послужил мне очень хорошо. PLY предоставляет вам чистый Python-фреймворк для построения токенов-основателей на основе lex и LR-парсеров на основе yacc .

Я пошел по этому пути, когда обнаружил проблемы с производительностью при разборе.

Вот несколько старая, но все еще интересная статья о разборе Python, включающая тесты для ANTLR, PLY и pyparsing . PLY примерно в 4 раза быстрее, чем pyparsing в этом тесте.

Answer 5

Невозможно узнать, какую выгоду вы получите, не просто протестировав ее, но есть вероятность, что вы сможете получить 10-кратную выгоду, просто используя Unladen Swallow , если ваш процесс длительныйБегущий и повторяющийся.(Кроме того, если вам нужно проанализировать много вещей, и вы обычно запускаете новый интерпретатор для каждого из них, Unladen Swallow становится быстрее - в какой-то мере - чем дольше вы запускаете свой процесс, поэтому при разборе одного ввода может не быть большой выгоды, выполучить значительный выигрыш на 2-м и 3-м входах в одном и том же процессе).

(Примечание: извлеките последнюю версию из SVN - вы получите гораздо лучшую производительность, чем последний тарбол)