Learn Kotlin - Performance Optimization

#Introduction

Correct code isn't necessarily fast. Episode 15 covers performance optimization for Kotlin applications: tuning the JVM, using language features like inline functions and reified types, managing memory deliberately, and measuring the impact with profiling tools.

A key point from the start: optimization without measurement is guesswork. You'll learn to identify bottlenecks with the right tools, then apply patterns that fix real problems — not premature optimizations that make the code unreadable.

After this episode, you'll know where to look for performance issues and which Kotlin patterns genuinely help.

#JVM Tuning for Kotlin Applications

#Heap and Garbage Collector

Kotlin applications run on the JVM, so heap behavior and the garbage collector determine performance. JVM flags set the initial and maximum heap sizes:

java -Xms512m -Xmx2g -XX:+UseG1GC -jar aplikasi.jar

-Xms512m sets an initial heap of 512 MB, -Xmx2g caps the maximum heap at 2 GB, and -XX:+UseG1GC selects G1GC — a balanced default for server applications. A heap that's too small triggers GC too often; one that's too large adds pauses and wastes memory.

#Observing GC

Before changing configuration, observe GC behavior with logging:

java -Xlog:gc -jar aplikasi.jar

The -Xlog:gc output shows GC frequency and duration. If GC takes up too much time, consider adjusting the heap or using a different collector. This logging data is the basis for decisions, not feelings.

#Inline Functions and Reified Types

#inline to Remove Lambda Overhead

Every lambda creates a function object. On hot paths, this overhead can add up. inline eliminates the lambda object by copying the function body to the call site:

Inline function

inline fun <T> jalankanTerkunci(lock: Any, blok: () -> T): T {
    synchronized(lock) {
        return blok()
    }
}

An inline function tells the compiler to embed the body at the call site, eliminating lambda object allocation. The standard library uses inline for collection operations like map and filter — that's why they feel lightweight.

#reified for Using Types at Runtime

In a regular generic function, the generic type is erased at runtime. With reified, the type stays available inside an inline function:

Reified type

inline fun <reified T> cari(): List<T> {
    return daftar.filterIsInstance<T>()
}

filterIsInstance<T>() is only possible because reified keeps the type at runtime. The reified pattern is very common in serialization and navigation libraries. Remember: reified only works in inline functions.

#Memory Management and Allocation Minimization

#Avoiding Unnecessary Allocations

The JVM handles garbage collection, but excessive allocation still costs. Some patterns that reduce allocation on hot paths:

• Use sequence for chains of operations over large data (episode 5).
• Avoid creating an object per iteration if a primitive variable works.
• Leverage value class to wrap values without allocation (episode 6).
• Be careful with closures that capture many variables.

Pola minimasi alokasi

val jumlahGenap = (1..1_000_000)
    .asSequence()
    .filter { it % 2 == 0 }
    .count()

asSequence() avoids creating an intermediate list at every operation. For millions of elements, this allocation difference is significant even though the code looks identical.

#Profiling to Find Real Problems

Don't guess. Profiling tools reveal the real hot spots:

java -XX:StartFlightRecording=duration=60s,filename=profile.jfr -jar aplikasi.jar
jcmd aplikasi.jar JFR.dump filename=profile.jfr

-XX:StartFlightRecording records a Java Flight Recorder session for 60 seconds, and jcmd fetches the dump. JFR is a built-in JVM profiler with low overhead — the right starting point before tools like async-profiler or YourKit.

#Optimization Patterns with Real Impact

#Order of Investigation

Some optimization patterns worth mastering:

• Reduce GC pressure: minimize allocations on hot paths with sequences and value classes.
• Cut object creation: reuse the same object for repeated work.
• Inline wisely: only on small functions called very frequently.
• Choose the right data structure: arrayList for index access; linkedList is rarely needed.
• Avoid reflection on hot paths; replace it with reified or specialized code.

#When to Stop

Optimization has a limit of benefit. Measure before and after, compare the results, and stop when improvements no longer matter. Readable, tested code is still more valuable than fast code that can't be maintained.

#Closing

Episode 15 optimized Kotlin application performance: JVM tuning with heap and G1GC, observing GC through logging, inline functions and reified types, minimizing allocations with sequences and value classes, and profiling with JFR before making decisions.

The key takeaways:

• Measure first with profiling before changing anything.
• -Xms and -Xmx set heap sizes; G1GC is a good default.
• inline removes lambda overhead; reified keeps types at runtime.
• Sequences and value classes reduce allocations on hot paths.
• JFR is a built-in JVM profiler with low overhead.
• Optimization that isn't readable or measured is technical debt.

In episode 16 we'll discuss metaprogramming and DSL — building DSLs with Kotlin syntax, type-safe builders with lambda receivers, annotation processors with kapt versus KSP, and reflection and compile-time features that power libraries.