Belajar Kotlin - Performance Optimization

#Pendahuluan

Kode yang benar belum tentu cepat. Episode 15 membahas performance optimization untuk aplikasi Kotlin: men-tuning JVM, memakai fitur bahasa seperti inline functions dan reified types, mengelola memori secara sadar, dan mengukur dampak dengan profiling tools.

Poin penting sejak awal: optimasi tanpa pengukuran adalah tebakan. Kalian akan belajar mengidentifikasi bottleneck dengan alat yang tepat, lalu menerapkan pola yang memperbaiki masalah nyata — bukan optimasi prematur yang membuat kode tidak terbaca.

Setelah episode ini, kalian akan tahu di mana harus mencari masalah performa dan pola Kotlin mana yang benar-benar membantu.

#JVM Tuning untuk Aplikasi Kotlin

#Heap dan Garbage Collector

Aplikasi Kotlin berjalan di atas JVM, jadi perilaku heap dan garbage collector menentukan performa. Flag JVM mengatur ukuran heap awal dan maksimum:

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

-Xms512m menetapkan heap awal 512 MB, -Xmx2g membatasi heap maksimum 2 GB, dan -XX:+UseG1GC memilih G1GC — default yang seimbang untuk aplikasi server. Ukuran heap yang terlalu kecil memicu GC terlalu sering; terlalu besar menambah pause dan memori terbuang.

#Mengamati GC

Sebelum mengubah konfigurasi, amati perilaku GC dengan logging:

java -Xlog:gc -jar aplikasi.jar

Output -Xlog:gc menampilkan frekuensi dan durasi GC. Jika GC memakan banyak waktu, pertimbangkan menyesuaikan heap atau memakai collector lain. Data logging ini adalah dasar keputusan, bukan perasaan.

#Inline Functions dan Reified Types

#inline untuk Menghapus Overhead Lambda

Setiap lambda menciptakan objek function. Pada hot path, overhead ini bisa terlihat. inline menghilangkan objek lambda dengan menyalin body fungsi ke tempat pemanggilan:

Inline function

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

Fungsi inline mengarahkan compiler untuk menanamkan body ke titik panggil, menghilangkan alokasi objek lambda. Standard library memakai inline pada operasi collection seperti map dan filter — itulah mengapa penggunaannya terasa ringan.

#reified untuk Memakai Tipe di Runtime

Pada fungsi generik biasa, tipe generik terhapus saat runtime. Dengan reified, tipe tetap tersedia di dalam fungsi inline:

Reified type

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

filterIsInstance<T>() hanya mungkin karena reified mempertahankan tipe di runtime. Pola reified sangat umum di library serialization dan navigasi. Ingat: reified hanya bisa dipakai pada fungsi inline.

#Memory Management dan Minimasi Alokasi

#Menghindari Alokasi yang Tidak Perlu

JVM menangani garbage collection, tetapi alokasi berlebihan tetap biaya. Beberapa pola yang mengurangi alokasi di hot path:

• Pakai sequence untuk rantai operasi data besar (episode 5).
• Hindari membuat objek per iterasi jika bisa memakai variabel primitif.
• Manfaatkan value class untuk membungkus nilai tanpa alokasi (episode 6).
• Hati-hati dengan closure yang menangkap banyak variabel.

Pola minimasi alokasi

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

asSequence() menghindari pembuatan list perantara di setiap operasi. Untuk jutaan elemen, perbedaan alokasi ini signifikan meskipun kode terlihat sama.

#Profiling untuk Menemukan Masalah Nyata

Jangan menebak. Profiling tools mengungkap hot spot sebenarnya:

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

-XX:StartFlightRecording merekam Java Flight Recorder selama 60 detik, dan jcmd mengambil dump-nya. JFR adalah profiler bawaan JVM dengan overhead rendah — titik awal yang tepat sebelum memakai alat seperti async-profiler atau YourKit.

#Pola Optimasi yang Berdampak

#Urutan Penyelidikan

Beberapa pola optimasi yang perlu dikuasai:

• Reduce GC pressure: minimasi alokasi di hot path dengan sequence dan value class.
• Kurangi pembuatan objek: gunakan object yang sama untuk pekerjaan berulang.
• Inline secara bijak: hanya pada fungsi kecil yang dipanggil sangat sering.
• Pilih struktur data tepat: arrayList untuk akses index, linkedList jarang dibutuhkan.
• Avoid reflection di hot path; ganti dengan reified atau kode khusus.

#Kapan Berhenti

Optimasi punya batas manfaat. Ukur sebelum dan sesudah, bandingkan hasilnya, dan berhenti ketika peningkatan tidak lagi berarti. Kode yang terbaca dan diuji tetap lebih berharga daripada kode cepat yang tidak bisa dipelihara.

#Penutup

Episode 15 mengoptimalkan performa aplikasi Kotlin: tuning JVM dengan heap dan G1GC, observasi GC lewat logging, inline functions dan reified types, minimasi alokasi dengan sequence dan value class, serta profiling dengan JFR sebelum mengambil keputusan.

Inti yang harus dibawa pulang:

• Ukur dulu dengan profiling sebelum mengubah apa pun.
• -Xms dan -Xmx mengatur ukuran heap; G1GC adalah default yang baik.
• inline menghapus overhead lambda; reified mempertahankan tipe di runtime.
• Sequence dan value class mengurangi alokasi di hot path.
• JFR adalah profiler bawaan JVM yang overhead-nya rendah.
• Optimasi yang tidak terbaca dan tidak terukur adalah utang teknis.

Di episode 16 selanjutnya kita akan membahas metaprogramming dan DSL — membangun DSL dengan sintaks Kotlin, type-safe builders dengan lambda receiver, annotation processors dan kapt versus KSP, serta reflection dan fitur compile-time yang memberdayakan library.