lex 和 yacc 提供优化代码吗？
Lex和Yacc是否提供优化的代码，或者是否需要我们手动编写自己的代码以获得更高的性能？
Do Lex and Yacc provide optimized code or is it required that we write our own code manually for higher performance?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您编写的代码对速度有很大影响，尤其是在词法分析器方面。某些版本的 Flex 附带了六种（左右）不同的字计数器，大多数是用 Flex 编写的，还有一些是手工编写的 - 代码很好地说明了如何优化扫描速度（以及相当合理的比较您可以在手写词法分析器与机器生成的词法分析器中期待什么）。
在解析器方面，您通常会受到更多限制——您无法在不影响语义的情况下进行尽可能多的更改。这里，很大程度上取决于您使用的解析器生成器 - 例如，一些针对较少约束的语法的算法始终会生成相对较慢的解析器，而其他算法仅针对较少约束的结构而减慢速度，并且只要输入不使用更复杂的结构。
The code you write has a substantial effect on the speed, especially on the lexer side. Some versions of Flex come with half a dozen (or so) different word counters, most written with Flex, and a few written by hand -- the code gives a pretty good idea of how to optimize scanning speed (and a fairly reasonable comparison of what you can expect in hand-written vs. machine generated lexers).
On the parser side, you're generally a bit more constrained -- you can't make as many changes without affecting the semantics. Here, a great deal depends on the parser generator you use -- for example, some algorithms for less constrained grammars consistently produce relatively slow parsers, while other algorithms only slow down for the less constrained constructs, and run relatively fast as long as the input doesn't use the more complex constructs.
Yacc 生成一个表驱动的解析器，它永远不可能像编写良好的手工编码的解析器一样快。我不知道这是否同样适用于 lex。
Yacc produces a table-driven parser, which can never be as fast as a well-written hand-coded one. I don't know if the same applies to lex.