When should I (and should I not) use Scala's @inline annotation?

Graham Lea picture Graham Lea · Jan 4, 2011 · Viewed 8.7k times · Source

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.

So I want to know:

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

  • 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?

Answer

oxbow_lakes picture oxbow_lakes · Jan 4, 2011

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
}

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.