Inline functions

Inline functions in Kotlin and when to use them, inline getters and setters, and crossinline.

— — — — — — — — — — — — — — —

THE CURRENT VERSION OF THIS ARTICLE IS PUBLISHED HERE.

— — — — — — — — — — — — — — —

Tags: #FYI

This article is part of the Kotlin Primer, an opinionated guide to the Kotlin language, which is indented to help facilitate Kotlin adoption inside Java-centric organizations. It was originally written as an organizational learning resource for Etnetera a.s. and I would like to express my sincere gratitude for their support.

It is recommended to read the Introduction before moving on. Check out the Table of Contents for all articles.

Using higher order functions will quickly become second nature to you, especially once you find out for yourself how powerful this programming style is. However, there ain’t no such thing as a free lunch — if you’re writing performant code, lambdas are expensive.

Each function is an object, and it captures a closure, i.e. the variables that are defined outside the function, which are accessed in the body of the function. Memory allocations (both for function objects and classes) and virtual calls introduce runtime overhead.

Thankfully, in many cases this kind of overhead can be eliminated by inlining the lambda expressions.

Take the definition of the map function:

In this case, whenever map is called, a lambda object must be created with all the overhead described before. However, we would be perfectly fine if, instead, the definition of the map function was just "copy-pasted" (i.e. inlined) where it was called. In essence, what we want the above call to mean is (roughly):

Naturally, that’s not exactly what will happen (e.g. we don’t want the result variable to pollute our scope), but roughly speaking, that's what we mean - we just don't want to write it out every time.

This is precisely what the inline keyword is for:

I know we haven’t covered these things yet, but just so you know, you can do the same things with properties without backing fields:

It’s probably kinda-sorta-intuitively understandable what we’re doing here, and we’ll cover the details very soon. Just make a mental note and don’t worry about it for now.

There are some technicalities that sometimes need to be taken care of with the crossinline keyword, but we won't go into those - feel free to peruse the documentation on inline functions.

We’ll revisit the topic of inline functions again when we talk about reified type parameters in later sections, another very cool Kotlin feature.

In practice — whenever you define a higher-order function, always try adding the inline keyword. If it works, excellent, you just made your code more performant. The compiler will always let you know when you need to add the crossinline keyword, or when you do something that's not allowed.

Go back to Function Types & Literals, jump to the Table of Contents, or continue to Tail Recursive Functions.