私は、大規模で純粋なPythonアプリケーションの一部としてpyparsing用に開発された巨大な文法を持っています。パフォーマンスの調整の限界に達し、収穫逓減によって他の場所を探し始めるようになりました。はい、私はほとんどのヒントとコツを知っていると思います。文法とほこりへの応用をプロファイリングしました。
次は何？
私は、同じ読みやすさ、使いやすさ（解析されている入力の後処理を開始するための解析アクションなど、pyparsingの多くの高度な機能を使用しています）、およびpython統合を10倍で提供するパーサーを見つけたいと思っています。パフォーマンス。
文法が純粋なPythonであるという事実が大好きです。
私の基本ブロックはすべて正規表現なので、再利用するといいでしょう。
私はすべてを手に入れることができないことを知っているので、要求された10倍のパフォーマンスを得るために今日持っている機能のいくつかをあきらめたいと思っています。
ここからどこへ行くの？
pyparsingの人々があなたの問題を予期していたようです。https://github.com/pyparsing/pyparsing/blob/master/HowToUsePyparsing.rstから：
pyparsing複雑な文法や大きな入力文字列の場合、のパフォーマンスが遅くなる可能性があります。このpsycoパッケージを使用すると、pyparsing文法やプログラムロジックを変更することなく、モジュールの速度を向上させることができます。観察された改善は20〜50％の範囲です。
ただし、以下のコメントでVangelが指摘しているように、psyco2012年3月の時点で廃止されたプロジェクトです。その後継はPyPyプロジェクトであり、パフォーマンスに対する同じ基本的なアプローチから始まります。バイトコードインタープリターの代わりにJITネイティブコードコンパイラを使用します。Python実装の切り替えがうまくいく場合は、PyPyで同等以上の利益を達成できるはずです。
あなたが本当にスピードデーモンであるが、読みやすさと宣言型構文の一部を維持したい場合は、ANTLRを見てみることをお勧めします。おそらくPythonを生成するバックエンドではありません。それが成熟しているのか、それともあなたのニーズに十分に対応できる高性能なのか、私は懐疑的です。私は商品について話している：それをすべて始めたCバックエンド。
パーサーへのエントリポイントの周りにPythonC拡張モジュールをラップし、緩めます。
そうは言っても、この移行では多くのことを諦めることになります。基本的に、パーサーで実行するPythonはすべて、C APIを介して実行する必要があります（完全にきれいではありません）。また、あなたは物事を行うための非常に異なる方法に慣れる必要があります。ANTLRには魅力がありますが、コンビネータに基づいていないため、文法と言語の間に、pyparsingにあるような簡単で流動的な関係はありません。さらに、これはlex / yaccによく似た独自のDSLであり、学習曲線を示すことができますが、LLベースであるため、ニーズに簡単に適応できる可能性があります。
生成されたC/C ++パーサーに切り替えます（ANTLR、flex / bisonなどを使用）。解析が完了するまですべてのアクションルールを遅らせることができる場合は、簡単なコードでASTを構築し、それをSWIGなどを介してPythonコードに戻し、現在のアクションルールで処理できる可能性があります。OTOH、それがあなたにスピードブーストを与えるために、構文解析は重労働でなければなりません。アクションルールが大きなコストである場合、Cでアクションルールを記述しない限り、これは何も購入しません（ただし、PythonとCコードの間で発生するインピーダンスの不一致の支払いを回避するためにとにかくそれを行う必要があるかもしれません） 。
大きな文法のパフォーマンスが本当に必要な場合は、SimpleParse（C拡張機能であるmxTextToolsに依存しています）よりも遠くを探す必要はありません。ただし、これには、より不可解であり、 EBNFに精通している必要があるという犠牲が伴うことを知っておいてください。
これは間違いなくPythonicのルートではなく、SimpleParseを使用するには、EBNF文法から最初からやり直す必要があります。
パーティーには少し遅れましたが、PLY（Python Lex-Yacc）は非常に役に立ちました。PLYは、lexベースのトークナイザーとyaccベースのLRパーサーを構築するための純粋なPythonフレームワークを提供します。
pyparsingでパフォーマンスの問題が発生したときに、このルートを選択しました。
これは、ANTLR、PLY、およびpyparsingのベンチマークを含む、Python解析に関するやや古いが、それでも興味深い記事です。このテストでは、PLYはpyparsingよりも約4倍高速です。
テストするだけでどのようなメリットが得られるかを知る方法はありませんが、プロセスが長時間にわたって繰り返される場合は、UnladenSwallowを使用するだけで10倍のメリットが得られる可能性があります。（また、解析するものがたくさんあり、通常、それぞれに対して新しいインタープリターを開始する場合、Unladen Swallowは、プロセスの実行時間が長くなるほど速くなります。したがって、1つの入力を解析しても、あまり効果がない場合があります。同じプロセスで2番目と3番目の入力で大幅なゲインが得られます）。
（注：SVNから最新のものを引き出す-最新のtarballよりもはるかに優れたパフォーマンスが得られます）