我问这个问题，是希望完善Simon Marlow对以前关于INLINABLE的问题的回答，该链接在此处:
Is there any reason not to use the INLINABLE pragma for a function?
我意识到这几乎是该问题的重复，只是西蒙·马洛(Simon Marlow)没有回答对许多图书馆作者来说最重要的关键问题:从纯粹的性能 Angular 来看，为所有内容添加INLINABLE编译指示是否安全？
据我所知，唯一的缺点是:*.hi)
但是我真正想知道的是，添加INLINABLE编译指示后，代码运行速度是否会变慢？换句话说，INLINABLE编译指示是否会导致GHC选择次优的优化？
我问的原因是，包括我本人在内的许多库作者都不在乎接口(interface)文件的大小，并且在添加INLINABLE编译指示时我们没有观察到编译速度显着下降，因此很容易将其反射性地添加到任何地方，因为这样做似乎没有成本。
相反，将它们排除在外的代价是，当模块变得非常大时，ghc开始有选择地从接口(interface)文件中省略某些功能以节省空间，这有时会导致优化效果变差，并且很难预测在何时会发生这种情况。以及它将省略哪些功能。
我个人从未见过由于INLINABLE注释而导致功能运行变慢的情况，但这可能完全是由于运气。如果有些情况下INLINABLE会使速度变慢，我想知道为什么这样做，这样我就可以更好地思考何时添加编译指示，而不是繁琐地对编译器编译指示的每个排列进行基准测试。
最佳答案
不知道这是否可以看作是纯粹的功能性观点，它肯定不是您问题的完整答案，但这只是一个问题。
从系统管理的 Angular 或观点来看，使所有内容都变为INLINEABLE意味着对任何功能的微小更改都会导致界面更改，并且您将获得一个新的包ID，并且需要根据此模块重新编译所有内容。
例如，这导致发行版出现问题:我们尝试将安全修复程序反向移植到Debian稳定版中。如果修复程序没有改变ABI，我们可以简单地更新一个软件包(并重建所有静态构建的程序)。如果确实更改了ABI，我们可能必须重建数十个或更多软件包。这样的问题对那些必须处理但并不特别在乎Haskell的人来说是let Haskell look bad。
关于haskell - 使用INLINABLE pragma的缺点，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/15440804/