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