令人难以置信的糟糕的解析时间

如何解决令人难以置信的糟糕的解析时间

我需要分析Elisp（Emacs Lisp）代码，因此我使用Instaparse为此编写了一个解析器。我以为它会很慢，但是即使在计算器（或我相当老的i7）上，每秒执行1k行的速度也太慢而无法正确执行。可能是那么糟糕，还是我做错了什么？

这是明确的，我尝试保持最低限度的向前/向后看，但是不幸的是，Elisp对于符号的构成非常自由，因此我不得不在该处添加一些向前/向后以区分数字和符号。另外，我尝试通过将符号，数字和关键字解析为“ ident”来弥补这一点，这仅给了我30％的时间。从我的测试来看，Instaparse似乎在递归规则上苦苦挣扎，而lisps具有高度递归的性质，所以也许我没有弄乱它-只是这么慢...

解析器：

(ns slowparse
  (:require [clojure.string :as str]
            [instaparse.combinators :as c]
            [instaparse.core :as insta]))

(def grammar
  "Elisp grammar."
  "<root> = any +

  <any> = sexp | keyword | number | symbol | prefix | string | vector |
          comment | whitespace | char | Epsilon

  comment = comment-tok #'(?:[^\\n]*|$)'

  string = <str-l-tok> #'(?:(?:\\\\\\\\)|(?:\\\\\")|[^\"])*' <str-r-tok>

  char = <char-tok> #'(?:(?:\\\\(?:C|M)-)|(?:\\\\))?(?:.|\\s)'

  <whitespace> = <#'\\s+'>

  sexp   = sexp-l-tok any + sexp-r-tok

  vector = vec-l-tok any + vec-r-tok

  <prefix>   = quote | template | spread | hole

  <prfxbl> = sexp | symbol | keyword | number | prefix | vector

  quote    = quote-tok prfxbl
  template = tmpl-tok prfxbl
  hole     = hole-tok ! spread-tok prfxbl
  spread   = hole-tok spread-tok prfxbl

  <sexp-l-tok>      = <'('>
  <sexp-r-tok>      = <')'>

  <vec-l-tok>       = <'['>
  <vec-r-tok>       = <']'>

  <str-l-tok>       = <'\"'>
  <str-r-tok>       = <'\"'>

  <quote-tok>       = '#' ? <\"'\">

  <tmpl-tok>        = <'`'>

  <num-b-x-tok>     = '#'

  <hole-tok>        = <','>

  <spread-tok>      = <'@'>

  <comment-tok>     = <';'>

  <char-tok>        = '?'

  <kv-tok>          = <':'>

  symbol    = ! ( number | kv-tok | comment-tok | num-b-x-tok | char-tok )
               ident

  keyword = kv-tok ident

  number    = num-b10 | num-bx
  <num-b10> = #'[-+]?(?:(?:[\\d]*\\.[\\d]+)|(?:[\\d]+\\.[\\d]*)|(?:[\\d]+))' &
              ( ! ident )
  <num-bx>  = #'(?i)#(?:b|o|x|(?:\\d+r))[-+]?[a-z0-9]+'")

(def ident
  {:ident
   (let [esc-ch (str/join ["\\[" "\\]" "\\(" "\\)" "\"" "\\s" "'" "," "`" ";"])
         tmpl "(?:(?:\\\\[{{ec}}])|[^{{ec}}])+"]
     (->> esc-ch (str/replace tmpl "{{ec}}") c/regexp c/hide-tag))})

(insta/defparser ^{:doc "Elisp parser."} elisp-parser
  (merge ident (c/ebnf grammar))
  :start :root)

(def test-text (slurp "/tmp/foo.el"))

(time (insta/parse elisp-parser test-text))

解决方法

按照@akond的建议，我将语法移植到ANTLR（使用https://github.com/aphyr/clj-antlr）。它可以在20毫秒或更短的时间内解析出1k行...是的，看起来Instaparse真的很慢。

不必进行太多更改，但是Instaparse无疑为编写规则感觉更好。它具有简单的排序和向前/向后看的标准正则表达式，是隐藏垃圾的简便方法。

ANTLR语法：

(ns fastparse
  (:require [clj-antlr.core :as antlr]))

(def grammar
  "Elisp grammar."
  "grammar EmacsLisp ;

   source: any* EOF ;

   any: list | keyword | number | symbol | prefix | string | vector | char |
        whitespace | comment;

   vector: '[' any* ']' ;

   list: '(' any* ')' ;

   prefix: quote | template | spread | hole ;

   quote: '#' ? '\\'' any ;

   template: '`' any ;

   spread: ',@' any ;

   hole: ',' any ;

   number: NUMB10 | NUMBX ;

   char: CHAR ;

   string: STRING ;

   keyword: KEYWORD ;

   symbol: IDENT ;

   whitespace: WS ;

   comment: COMLINE ;

   CHAR: '?' ( ( '\\\\' ( 'C' | 'M' ) '-' ) | '\\\\' )? . ;

   STRING: '\"' ( '\\\\\\\\' | '\\\\\"' | . )*? '\"' ;

   NUMB10: [+-] ? ( ( D* '.' D+ ) | ( D+ '.' D* ) | D+ ) ;

   NUMBX: '#' ( 'b' | 'o' | 'x' | ( D+ 'r' ) ) [-+]? ( A | D )+ ;

   fragment
   D: '0'..'9' ;

   fragment
   A: 'a'..'z' ;

   KEYWORD: ':' IDENT ;

   IDENT: ( ( '\\\\' [\\\\[\\]() \\n\\t\\r\"',`;] )+? |
            ( ~[[\\]() \\n\\t\\r\"',`;] )+? )+ ;

   COMLINE: ';' ~[\\n\\r]* ;

   WS: [ \\n\\t\\r]+ ;")

(def elisp-str->edn (antlr/parser grammar))

(def text (slurp "/tmp/foo.el"))

(time (elisp-str->edn text))

如果您对速度感兴趣，并且不想担心堆栈溢出的发生，可以尝试使用Tunnel Grammar Studio（我正在研究的解析器生成器）。从它生成的解析器在词法分析，树构造，树迭代，树到字符串转换和树释放期间是迭代。可接受的语法在ABNF（RFC 5234）中，每个标记区分大小写（RFC 7405）。

最好对您使用的任何解析器都具有确定性的语法。 TGS会在编译时检查LL（1）冲突，并通过可视化冲突位置来帮助您创建确定性语法。

该工具有一个演示，您可以自己测试速度。该工具中有一个选项可以生成完全准备就绪的测试用例项目，该项目将在运行时通过仅提供输入数据来解析，迭代树并释放它所花费的时间登录控制台。这意味着，如果您想测试语法速度，则不需要您进行任何开发（编译生成的代码除外）。

在我使用消除了歧义性的JSON语法（RFC 8259）进行的测试中，该迭代分析器仅发出语法树构建事件（如SAX），每秒运行大约8兆字节，这是很多每秒行数，并且仅占用与解析深度成比例的内存，因为从技术上讲，LL（1）语法在运行时只需要一个令牌，即实际上是在“流式处理”输入。

您还可以具有静态类型化或动态类型化的具体语法树，或具有不同抽象级别（即自动节点修剪）的动态类型化抽象语法树。这些树的语法树构建器（如果已选择）正在使用build事件来创建相关的树。但是，您将需要ABNF语法和C ++作为语言目标。

该工具支持解析器语法内的标记范围（除词法分析器语法内的字符范围外）。这意味着您无需额外注意词汇规则顺序即可开发语法。

令人难以置信的糟糕的解析时间

如何解决令人难以置信的糟糕的解析时间

解决方法

相关推荐