作为大型纯 Python 应用程序的一部分，我为 pyparsing 开发了一个巨大的语法。我已经达到了性能调整的极限，我正处于收益递减让我开始寻找其他地方的地步。是的，我想我知道大部分的技巧和窍门，而且我已经把我的语法和我的应用程序化为尘土。
接下来是什么？
我希望找到一个解析器，它可以给我同样的可读性、可用性（我正在使用 pyparsing 的许多高级功能，例如 parse-actions 来开始对正在解析的输入进行后处理）和 python 集成，但在 10 倍性能。
我喜欢语法是纯 Python 的事实。
我所有的基本块都是正则表达式，所以重用它们会很好。
我知道我不能拥有一切，所以我愿意放弃我今天拥有的一些功能，以达到要求的 10 倍性能。
我从这里去哪里？
看起来 pyparsing 的人已经预料到了你的问题。来自https://github.com/pyparsing/pyparsing/blob/master/HowToUsePyparsing.rst：
pyparsing对于复杂的语法和/或大的输入字符串，性能可能会很慢。该psyco软件包可用于提高pyparsing模块的速度，而无需更改语法或程序逻辑 - 观察到的改进已在 20-50% 范围内。
然而，正如 Vangel 在下面的评论中指出的psyco那样，截至 2012 年 3 月，它是一个过时的项目。它的继任者是PyPy项目，它从相同的基本性能方法开始：使用 JIT 本机代码编译器而不是字节码解释器。如果切换 Python 实现对您有用，您应该能够使用 PyPy 获得类似或更大的收益。
如果你真的是一个速度恶魔，但想保持一些易读性和声明性语法，我建议你看看 ANTLR。可能不是 Python 生成的后端；我怀疑这是否足够成熟或高性能以满足您的需求。我说的是商品：启动这一切的 C 后端。
在解析器的入口点周围包裹一个 Python C 扩展模块，然后松开它。
话虽如此，您将在此过渡中放弃很多：基本上您想在解析器中执行的任何 Python 都必须通过 C API 完成（并不完全漂亮）。此外，您必须习惯于非常不同的做事方式。ANTLR 有它的魅力，但它不是基于组合子的，所以你的语法和你的语言之间没有 pyparsing 中那种简单流畅的关系。另外，它是它自己的 DSL，很像 lex/yacc，它可以呈现一个学习曲线——但是，因为它是基于 LL 的，你可能会发现它更容易适应你的需求。
切换到生成的 C/C++ 解析器（使用 ANTLR、flex/bison 等）。如果您可以将所有操作规则延迟到完成解析之后，您可能能够使用简单的代码构建一个 AST，然后通过 SWIG 之类的东西将其传递回您的 python 代码，并使用您当前的操作规则对其进行处理。OTOH，为了提高速度，解析必须是繁重的工作。如果您的操作规则是最大的成本，那么除非您也用 C 编写您的操作规则，否则这不会给您带来任何好处（但您可能无论如何都必须这样做，以避免为您在 python 和 C 代码之间获得的任何阻抗不匹配付出代价） .
如果您真的想要大型语法的性能，只需看看SimpleParse（它本身依赖于 mxTextTools，一个 C 扩展）。但是，现在知道它的代价是更加神秘，并且要求您精通EBNF。
这绝对不是更 Pythonic 的路线，您必须从 EBNF 语法重新开始才能使用 SimpleParse。
聚会有点晚了，但是PLY (Python Lex-Yacc)对我很有帮助。PLY 为您提供了一个纯 Python 框架，用于构建基于 lex 的标记器和基于 yacc 的LR 解析器。
当我遇到 pyparsing 的性能问题时，我选择了这条路线。
这是一篇关于 Python 解析的旧文章，但仍然很有趣，其中包括ANTLR、PLY 和 pyparsing 的基准。在这个测试中，PLY 比 pyparsing 快大约 4 倍。
如果不对其进行测试，就无法知道您将获得什么样的好处，但如果您的过程长期运行且重复，则仅使用Unladen Swallow就有可能获得 10 倍的好处。（另外，如果你有很多东西要解析，并且你通常为每一个都启动一个新的解释器，Unladen Swallow 会变得更快——在某种程度上——你运行进程的时间越长，所以在解析一个输入时可能不会显示太多收益，你可能在同一过程中获得第二和第三输入的显着收益）。
（注意：从 SVN 中提取最新的 - 你将获得比最新的 tarball 更好的性能）