我什么时候应该(也应该不)使用Scala的@inline注释? [英] When should I (and should I not) use Scala's @inline annotation?

问题描述

我相信我了解内联函数的基础:不是将函数调用导致将参数放置在堆栈上并发生调用操作，而是在编译时将函数的定义复制到进行调用的位置，从而节省了时间运行时的调用开销.

I believe I understand the basics of inline functions: instead of a function call resulting in parameters being placed on the stack and an invoke operation occurring, the definition of the function is copied at compile time to where the invocation was made, saving the invocation overhead at runtime.

所以我想知道:

• scalac是否使用smart内联某些功能(例如private def)而没有注释的提示?

• Does scalac use smarts to inline some functions (e.g. private def) without the hints from annotations?

我该如何判断何时暗示scalac内联函数是一个好主意?

How do I judge when it be a good idea to hint to scalac that it inlines a function?

任何人都可以共享应该或不应该内联的函数或调用的示例吗?

Can anyone share examples of functions or invocations that should or shouldn't be inlined?

推荐答案

从不@inline任何其实现可能会发生合理变化并且将成为库的 public 部分的内容.

Never @inline anything whose implementation might reasonably change and which is going to be a public part of a library.

当我说实现改变"时，我的意思是逻辑实际上可能会改变.例如:

When I say "implementation change" I mean that the logic actually might change. For example:

object TradeComparator extends java.lang.Comparator[Trade] {
  @inline def compare(t1 : Trade, t2 : Trade) Int = t1.time compare t2.time
}

比方说，自然比较"随后更改为基于原子计数器.您可能会发现一个应用程序最终包含2个组件，每个组件都是针对不同版本的比较代码构建和内联的.

Let's say the "natural comparison" then changed to be based on an atomic counter. You may find that an application ends up with 2 components, each built and inlined against different versions of the comparison code.

这篇关于我什么时候应该(也应该不)使用Scala的@inline注释?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！