The Hidden Cost of Kotlin Inline Functions

For a long time, inline felt like a free performance button. If a function accepted a lambda, I reached for inline. If a utility was small, I reached for inline. Then I started looking at generated bytecode and APK size. The uncomfortable truth was simple: inline can remove overhead, but it can also duplicate code everywhere you call it.

Core promise

Explain both sides of Kotlin inline functions: performance benefits and bytecode/dex-size tradeoffs.

Section 1: Why inline exists

inline fun transaction(block: () -> Unit) {
    beginTransaction()
    try {
        block()
        commit()
    } catch (t: Throwable) {
        rollback()
        throw t
    }
}

Inlining avoids creating a function object for block in many cases.

Section 2: Good inline use cases

• Small higher-order utility functions
• Performance-sensitive repeated calls
• APIs using reified generics

Reified example

inline fun <reified T> Moshi.fromJson(json: String): T? {
    return adapter(T::class.java).fromJson(json)
}

Without reified, you cannot access T::class.java like this.

Section 3: Bad inline use case

inline fun renderHugeTemplate(block: () -> Unit) {
    // many lines of code
    // many branches
    // lots of object creation
    block()
}

If this function is called from many places, the body can be copied many times.

Section 4: Use noinline when needed

inline fun registerHandler(
    name: String,
    noinline handler: () -> Unit
) {
    handlers[name] = handler
}

You need noinline when storing the lambda.

Section 5: Practical rule

Use inline when:

• function is small
• function takes lambda parameters
• function is called often
• avoiding lambda allocation matters
• you need reified

Avoid or reconsider when:

• function body is large
• function is rarely called
• APK/dex size matters
• you are inlining just because it feels faster

inline is not magic. It is a trade: fewer call/lambda overheads in exchange for copied code. Use it like a scalpel, not like a paint roller.