是否有任何理由不使用INLINABLE编译指示功能？

问题描述

指出：

缺点是什么它是什么？

它是否使界面文件更大，更大？它是否会使编译速度变慢？

是否有任何理由不应该在我编写的每个导出函数上放置INLINABLE编译指示？有没有什么原因GHC不会在我写的每个导出函数上放置一个INLINABLE编译指示？

使用 INLINABLE并且根本不使用pragma：

• 如果没有INLINABLE，接口文件中的定义是代码在优化之后，而使用INLINABLE时，它是您编写的代码（或多或少）。特别是，如果没有INLINABLE，GHC可能会将其他函数内联到函数的定义中。
  

• 如果没有INLINABLE，GHC将会从接口文件中删除定义，如果它太大。如果其他功能内嵌到右侧，这可以很容易地将其推到极限。

INLINABLE还会打开一些智能机器，专用于使用它们的重载函数，并与其他模块共享专用版本，这些模块可以传输导入创建专用版本的模块。

The documentation states:

What's the disadvantage of it?

Does it make interface files much, much bigger? Does it make compilation much slower?

Is there any reason I shouldn't put an INLINABLE pragma on every exported function I write? Is there any reason GHC doesn't put an INLINABLE pragma on every exported function I write?

解决方案

There are three differences between using INLINABLE and not using a pragma at all:

• Without INLINABLE, the definition that goes in the interface file is the code after optimisation, whereas with INLINABLE, it is the code you wrote (more or less). In particular, without INLINABLE, GHC might inline other functions into the function's definition.

• Without INLINABLE, GHC will omit the definition from the interface file if it is too big. If some other function got inlined into the right-hand-side, this could easily push it over the limit.

• INLINABLE also turns on some clever machinery that automatically specialises overloaded functions where they are used, and shares the specialised versions with other modules that transitively import the module in which the specialised version was created.

这篇关于是否有任何理由不使用INLINABLE编译指示功能？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！