lti*_*mer 6 javascript parsing templates tokenize lexer
我正在编写一个用于编译成JS的模板语言的解析器(如果相关的话).我从一些简单的正则表达式开始,这似乎有效,但正则表达式非常脆弱,所以我决定编写一个解析器.我开始编写一个简单的解析器,通过推送/弹出堆栈来记住状态,但事情不断升级,直到我手上有一个递归下降解析器.
不久之后,我比较了以前所有解析方法的性能.递归下降解析器是迄今为止最慢的.我被困了:是否值得使用递归下降解析器来处理简单的事情,或者我是否有理由采取快捷方式？我很想去纯粹的正则表达式路线,这种路线非常快(几乎比RD解析器快3倍),但在某种程度上非常黑客且无法维护.我认为性能并不是非常重要,因为编译模板是缓存的,但是递归下降解析器是每个任务的正确工具吗？我想我的问题可以被视为更具哲学性的问题:在多大程度上牺牲性能的可维护性/灵活性是值得的？
递归下降解析器可以非常快.
这些通常使用词法分析器进行组织,使用正则表达式来识别提供给解析器的语言标记.处理源文本的大部分工作都是由词法分析器逐个字符完成的,使用RE经常被编译成的疯狂快速的FSA.
解析器偶尔会看到令牌与词法分析器看到字符的速率相比,因此它的速度通常无关紧要.然而,当比较解析器到解析器的速度,忽略lex令牌所需的时间时,递归下降解析器可以非常快,因为它们使用函数调用实现解析器堆栈,与一般解析器push-current-state-相比,函数调用已经非常有效在模拟的堆栈.
所以,你也可以吃蛋糕,也可以吃.使用regexps作为词位.使用解析器(任何类型,递归下降都很好)来处理词位.你应该对表现感到满意.
这种方法也满足了其他答案所做的观察:以一种使其可维护的方式编写它.我保证,Lexer/Parser分离非常好.
| 归档时间： |
|
| 查看次数： |
2141 次 |
| 最近记录： |