我问这个问题是为了完善 Simon Marlow 对上一个问题给出的答案INLINABLE，链接在这里：
有什么理由不对函数使用 INLINABLE pragma 吗？
我意识到这几乎是那个问题的重复，除了 Simon Marlow 没有回答对许多图书馆作者来说最重要的关键问题：从纯粹的性能角度来看，只INLINABLE为所有内容添加 pragma 是否安全？
据我所知，唯一的缺点是：
较慢的编译时间
较大的接口文件（即
*.hi）
但我真正想知道的是代码是否会因为添加INLINABLE编译指示而运行得更慢？换句话说，INLINABLE编译指示是否会导致 GHC 选择不太理想的优化？
我问的原因是，包括我自己在内的许多库作者并不关心接口文件的大小，并且在添加INLINABLEpragma 时我们没有观察到编译速度明显减慢，因此很容易在任何地方反射性地添加它们，因为这样做似乎没有任何成本。
相反，将它们排除在外的代价是，当模块变得非常大时，ghc开始有选择地从接口文件中省略一些函数以节省空间，这有时确实会导致更糟糕的优化，并且很难预测这会在什么时候发生，并且它将省略哪些功能。
我个人从未见过由于INLINABLE注释而导致函数运行速度变慢，但这可能完全是由于运气。如果在某些情况下INLINABLE会减慢速度，我想知道为什么会这样，以便我可以更好地推断何时添加编译指示，而不是对编译器编译指示的每个排列进行乏味的基准测试。