Elm 编译器永远运行，计算机刚刚变热

Posted 2023-02-19

【中文标题】Elm 编译器永远运行，计算机刚刚变热

【英文标题】：Elm Compiler running forever, computer just getting hot

【发布时间】：2016-08-28 23:56:36

【问题描述】：

我不确定是什么导致了这个问题，但是在我正在构建的一个项目中，编译器只需要几个小时来编译一个模块。我的代码库总大小为 352KB，但没有一个模块超过 10KB。我正在使用本机端口，但这很简单；我只是用它来获取Date.now()。

有什么众所周知的东西会导致 elm 编译器永远编译吗？我没有很多依赖项，但我经常使用 html。我真的很感激任何关于导致这种情况的提示。

编辑

事实证明大写表达式会导致优化器花费很长时间，从 0.16 开始。这是提出问题的discussion on Elm-Discuss 和gist of the nasty case match。

我想是冗长并保留一个胡萝卜，为什么 elm 的编译器会采用这种方式进行大小写匹配？这里的底层机制是什么？为什么编译器在一个 case 语句上优化 60 多个模式匹配需要超过一个小时？

【问题讨论】：

我很好奇。 Elm 编译器执行了什么样的优化，编译一个 case 表达式需要几个小时？您的案例表达式似乎不太大（至少对于计算机来说不够大）。这意味着 Elm 编译器有一个非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常非常糟糕的优化算法。例如，想象一下它需要多长时间来编译包含所有 721 只神奇宝贝的 case 表达式。

我猜答案就在here，也许你应该尝试添加haskell标签，看看haskell人是否可以向我们透露一些信息。

我认为您应该在更好的场所提出一个关于修复案例内容的新问题，并通过解释案例内容已知缓慢来回答您自己的问题。至于为什么，相关代码看起来在这里：github.com/elm-lang/elm-compiler/blob/master/src/Optimize 引用的 Scott & Ramsey 论文描述了“小分支因子”启发式是如何极其缓慢的。在上面的代码中，当小的默认值平局时，启发式被用作决胜局。所以，我打赌你的坏例子，小默认关系很多，我们遇到了可怕的情况。我的看法：Elm 不应该使用 SBF 作为一个因素，句号。

能否请您自行回答此问题，使其不再出现在未回答列表中？

它真的完成编译了吗？

【参考方案1】：

大写表达式会导致优化器花费很长时间，从 0.16 开始。这是提出问题的discussion on Elm-Discuss 和gist of the nasty case match。