我正在问这个问题，希望能够完善Simon Marlow之前关于INLINABLE的问题的答案，链接在这里：
Is there any reason not to use the INLINABLE pragma for a function?
我意识到这几乎是这个问题的重复，除了Simon Marlow没有回答对许多图书馆作者来说最重要的关键问题：从纯粹的绩效角度看它是否安全 只是将INLINABLE pragma添加到所有内容中？
据我所知，唯一的缺点是：
编译时间较慢
较大的界面文件（即*.hi）
但我真正想知道的是，由于添加INLINABLE pragma，代码是否会运行得更慢？换句话说，INLINABLE pragma是否会导致GHC选择不太理想的优化？
我问的原因是许多库作者，包括我自己，不关心接口文件的大小，并且在添加INLINABLE编译指示时我们没有观察到编译的显着减慢，所以它很有吸引力只是反复地将它们添加到任何地方，因为这样做似乎没有任何成本。
相反，将它们遗漏的成本是当模块变得非常大时ghc开始有选择地从接口文件中省略一些函数以节省空间，这有时会导致更糟糕的优化，并且很难预测这将发生在什么时候以及它将省略哪些功能。
我个人从未目睹过INLINABLE注释导致函数运行速度较慢，但这可能完全归功于运气。如果有INLINABLE减慢事情的情况，我想知道它为什么这样做，以便我可以更好地推断何时添加编译指示而不是繁琐地对编译器编译指示的每个排列进行基准测试。
答案 0 :(得分：11)
不确定这是否符合纯粹的功能性观点，而且肯定不是您问题的完整答案，但它只是一点点。
从系统管理点或视图中，将所有内容设置为INLINEABLE意味着对任何函数的每个微小更改都会导致接口发生更改，并且您将获得新的包ID并需要根据此模块重新编译所有内容。
例如，这会导致发行版出现问题：我们尝试将安全修复程序反向移植到Debian stable中。如果修复程序没有更改ABI，我们可以简单地更新一个包（并重建所有静态构建的程序）。如果它确实改变了ABI，我们可能不得不重建dozends包或更多。这些问题let Haskell look bad给那些必须处理问题，但特别不关心Haskell的人。{/ p>