haskell - 使用 INLINABLE pragma 的缺点

Question

我问这个问题是为了完善 Simon Marlow 对先前关于 INLINABLE 的问题的回答。 ，链接在这里:

Is there any reason not to use the INLINABLE pragma for a function?

我意识到这几乎是那个问题的重复，除了 Simon Marlow 没有回答对许多图书馆作者来说最重要的关键问题:它安全吗从纯粹的性能角度来看只需添加 INLINABLE一切的语用？

据我所知，唯一的缺点是:

更慢的编译时间

更大的接口(interface)文件(即 *.hi )

但我真正想知道的是，添加 INLINABLE 后代码是否会运行得更慢。语用？换句话说， INLINABLE 可以吗？ pragma 是否会导致 GHC 选择不太理想的优化？

我问的原因是，包括我自己在内的许多库作者并不关心接口(interface)文件的大小，并且在添加 INLINABLE 时我们没有观察到编译速度明显减慢。 pragma，所以很容易在任何地方反射性地添加它们，因为这样做似乎没有任何成本。

相反，将它们排除在外的代价是当模块变得非常大时 ghc开始有选择地从接口(interface)文件中省略一些函数以节省空间，这有时确实会导致更糟糕的优化，并且很难预测这将在什么时候发生以及它将省略哪些函数。

我个人从未目睹过由于 INLINABLE 导致函数运行速度变慢的情况。注释，但这可能完全是由于运气。如果有 INLINABLE的情况减慢速度，我想知道为什么会这样，以便我可以更好地推理何时添加编译指示，而不是对编译器编译指示的每个排列进行乏味的基准测试。

Answer 1

不确定这是否符合纯粹的功能观点，它肯定不是您问题的完整答案，但它是一点点。

从系统管理的角度或角度来看，使所有内容都可以 INLINEABLE 意味着对任何功能的每一个微小更改都会导致接口(interface)发生变化，并且您会获得一个新的包 id，并且需要根据该模块重新编译所有内容。

例如，这会导致发行版出现问题:我们尝试将安全修复程序反向移植到 Debian stable 中的软件包。如果修复没有改变 ABI，我们可以简单地更新一个包(并重建所有静态构建的程序)。如果它确实改变了 ABI，我们可能不得不重建几十个或更多的包。此类问题let Haskell look bad对于那些必须处理问题，但特别不关心 Haskell 的人。