在 Erlang 束上使用透析器和源代码之间是否有任何效率差异

Question

我在类似~/erl_beam的路径下收集项目的所有光束文件

dialyzer ~/erl_beam/*.beam --get_warnings -o static_analysis.log

效果很好。

如果我在 Erlang 源代码上执行此操作：

dialyzer --get_warnings -I <Path1> --src <Path2> -o static_analysis.log

它也可以工作。

那么为什么我们有两种方法可以对 Erlang 代码进行静态分析呢？彼此之间有什么长处或短处吗？

Answer 1

非常小。

透析器分析在核心 Erlang 上进行。可以直接从+debug_info编译的.beam文件中提取此表示形式，也可以通过编译.erl文件来提取此表示形式。编译需要时间，但它当然不是分析中最耗时的部分。

如果您已经使用+debug_info编译了.erl，那么分析生成的.beam文件也更方便，因为您不必将任何与编译相关的命令行选项传递给 Dialyzer。

Answer 2

Dialyzer 从调试编译的 BEAM 字节码或 Erlang 源代码开始分析。 但是，有几个选项仅适用于 BEAM 文件（例如，--build_plt ）。

例如，如果您无权访问源文件，则可能需要使用 BEAM 文件。 如果您同时可以访问 BEAM 和源文件，则可能需要使用 BEAM 文件，因为这会稍微加快分析速度：透析器解析其输入所需的时间要少得多。 另一方面，解析花费的时间比其他分析要少得多，所以不要指望看到太大的差异（如果超过 10%，我会感到惊讶）。

除此之外，AFAIK，在这两种情况下，透析器执行的分析类型没有区别。