When to Use Inline Functions in Kotlin

By the end of this page, you will understand what Kotlin inline functions do, why they are mainly useful for higher-order functions, why lambdas in non-inline functions may still appear optimized, and how to decide whether inline is worth using in real code. You will also learn the trade-off between runtime overhead and code size.

Kotlin inline functions tell the compiler to copy the function body directly into the call site instead of generating a normal function call.

This matters most for higher-order functions: functions that take other functions, usually lambdas, as parameters.

Consider this function:

fun lock(lock: Lock, block: () -> Unit) {
    lock.lock()
    try {
        block()
    } finally {
        lock.unlock()
    }
}

This is a higher-order function because it accepts block, which is a function.

Without inline, the usual model is:

• the lambda may be represented as a function object
• that object is passed to lock
• lock calls block()

With inline, the compiler can replace the call with the actual code of both the function and the lambda.

inline fun lock(lock: , block: () -> ) {
    lock.lock()
     {
        block()
    }  {
        lock.unlock()
    }
}

Think of a normal higher-order function call like hiring a helper.

• You write down instructions in a lambda.
• The program wraps those instructions into a little object.
• The function receives that object and says, “Now execute these instructions.”

An inline function is more like skipping the helper entirely.

• Instead of packaging the instructions,
• the compiler pastes the instructions directly where the function is called.

So:

• non-inline = pass a callable package around
• inline = paste the code in place

If the instructions are tiny and used often, pasting them can be faster. If the instructions are large and used in many places, pasting them everywhere can make the program bigger.

The basic syntax is:

inline fun runAction(action: () -> Unit) {
    action()
}

Calling it:

runAction {
    println("Hello")
}

A more realistic example is a lock wrapper:

inline fun <T> withLock(lock: Lock, block: () -> T): T {
    lock.lock()
    return try {
        block()
    } finally {
        lock.unlock()
    }
}

Usage:

val result = withLock(myLock) {
    "done"
}

Why this is a good inline candidate

• The function body is small.
• It takes a lambda.
• It is a wrapper around common repeated logic.
• It may be called frequently.

Non-inline version

  : T {
    lock.lock()
      {
        block()
    }  {
        lock.unlock()
    }
}

Consider this inline function:

inline fun withMessage(block: () -> Unit) {
    println("Start")
    block()
    println("End")
}

And this call:

withMessage {
    println("Work")
}

Conceptual inline expansion

The compiler can treat it roughly like this:

println("Start")
println("Work")
println("End")

Step by step

1. The call to withMessage is found.
2. Because the function is marked inline, the compiler copies its body into the call site.
3. The lambda body is also copied into the place where block() appears.
4. The final code behaves like regular sequential code.

Compare with non-inline

fun withMessageNormal(block: () -> ) {
    println()
    block()
    println()
}

Inline functions are commonly used in situations like these:

Resource handling

inline fun <T> useResource(block: () -> T): T {
    println("open")
    return try {
        block()
    } finally {
        println("close")
    }
}

Useful for wrapping setup and cleanup logic.

Locking and concurrency

inline fun <T> withLock(lock: Lock, block: () -> T): T {
    lock.lock()
    return try {
        block()
    } finally {
        lock.unlock()
    }
}

This keeps critical-section code short and safe.

Collection utilities

Kotlin's standard library uses inline heavily in functions like:

• let
• run
• apply

In real projects, developers use inline selectively, not everywhere.

Common pattern: tiny wrappers around lambdas

inline fun <T> measure(block: () -> T): T {
    val start = System.nanoTime()
    return try {
        block()
    } finally {
        println(System.nanoTime() - start)
    }
}

This is common because the wrapper is small and the lambda is the main work.

Guard-style helper functions

inline fun ifDebug(block: () -> Unit) {
    if (BuildConfig.DEBUG) {
        block()
    }
}

If not in debug mode, the block is skipped. Inlining can reduce wrapper overhead.

Validation and error handling helpers

inline fun requireValid(condition: Boolean, lazyMessage: () -> String) {
    if (!condition)  IllegalArgumentException(lazyMessage())
}

1. Using inline on ordinary functions with no lambdas

inline fun add(a: Int, b: Int): Int {
    return a + b
}

This usually brings little value.

Better approach

Just write a normal function unless you have a measured reason.

fun add(a: Int, b: Int): Int = a + b

2. Assuming non-inline always creates a new object every call

Beginners often think this always happens:

• call function
• allocate a brand new lambda object
• invoke it

But the compiler may reuse a singleton for non-capturing lambdas, and the JVM may optimize further.

So the cost is often possible overhead, not always a guaranteed heavy overhead.

3. Inlining large functions

inline fun hugeFunction {
    
    
    
    block()
    
}

Quick rules

• Use inline mainly for small higher-order functions.
• The biggest benefit is with lambda parameters.
• Do not inline large functions without a reason.
• Do not expect huge gains automatically.
• Non-inline lambdas may still be optimized by the compiler or JVM.

Basic syntax

inline fun doWork(block: () -> Unit) {
    block()
}

Good candidates

• lock wrappers
• timing helpers
• validation helpers with lazy messages
• scope-style functions
• tiny DSL/builders

Usually bad candidates

• ordinary arithmetic or utility functions with no lambdas
• large functions called in many places
• code with no measurable overhead issue

Important terms

• higher-order function: a function that takes or returns another function
• lambda: an anonymous function like { println("Hi") }
• capturing lambda: a lambda that uses values from outer scope
• non-capturing lambda: a lambda that uses no outside variables

Why non-inline may still look cheap

Why doesn't a non-inline Kotlin lambda always create a new object?

Because the compiler can optimize non-capturing lambdas by reusing a singleton instance, and the JVM can apply further runtime optimizations.

Should I mark every higher-order function as inline?

No. Use inline when the function is small and the benefit is meaningful. Too much inlining increases code size.

Is inline only about performance?

No. It also enables language features such as non-local returns from lambdas.

Are inline functions always faster?

Not always. They can reduce call overhead, but they also increase bytecode size. The best choice depends on the function's size and usage.

When is inline most useful in Kotlin?

It is most useful for small wrapper functions that take lambdas, such as locking, resource handling, timing, logging, and scope-style utilities.

Why does Kotlin standard library use inline so often?

Because many standard functions are tiny higher-order utilities called frequently, so inlining often improves ergonomics and can reduce overhead.

Can I inline a function without lambda parameters?

Yes, but it is usually not helpful. Kotlin primarily benefits from inline when lambdas or reified type parameters are involved.

What is the simplest rule for beginners?

Default to normal functions. Reach for inline when writing a small higher-order helper and you understand the reason for using it.

• Higher-order functions — Inline functions are most useful when functions accept other functions as parameters.
• Lambdas in Kotlin — Understanding lambda syntax helps explain why inline exists.
• Closures and captured variables — Capturing outer variables affects how lambdas are represented.
• noinline and crossinline — These modifiers control how lambda parameters behave inside inline functions.
• Non-local returns — This is a major language feature enabled by inline lambdas.
• Scope functions — Functions like let, run, and apply are common inline examples.
• JVM optimization and JIT — Runtime optimizations explain why non-inline code may still perform well.
• Code size vs performance trade-offs — Inlining is a classic example of this engineering balance.