Belajar Zellij - Performance Optimization

#Pendahuluan

Episode 23 mengajarkan kalian menyelamatkan Zellij yang bermasalah. Episode 24 ini mengajarkan sesuatu yang lebih halus: bagaimana membuat Zellij tidak bermasalah sejak awal — dengan mengelola sumber daya secara sadar. Series Belajar Zellij menutup babak troubleshooting dan performance optimization dengan topik Performance Optimization di episode 24, sebelum melangkah ke ekosistem modern di episode 25.

Zellij pada dasarnya hemat: proses server Rust yang ramping dan plugin WASM yang ringan. Tetapi seperti semua terminal workspace, biaya tumbuh seiring penggunaan. Setiap pane adalah proses PTY yang hidup, setiap plugin merender UI secara periodik, setiap scrollback menyimpan ribuan baris di memori, dan setiap session yang diserialisasi menulis data ke disk. Pada mesin modern ini tidak terasa; di VPS kecil, laptop tua, atau container dengan batas ketat, perbedaannya sangat nyata.

Episode 24 menyusun tuning dari yang paling berdampak: scroll_buffer_size untuk mengendalikan memori scrollback, scrollback_lines_to_serialize untuk meringankan proses restore, tema sederhana untuk mengurangi beban renderer, strategi menjaga banyak session dan plugin tetap responsif, serta manajemen sumber daya di mesin terbatas secara menyeluruh. Tujuannya bukan performa ekstrem, melainkan workspace yang stabil dan nyaman di segala kondisi.

Sebelum masuk ke detail, penting untuk menetapkan ekspektasi yang realistis. Performance tuning di Zellij tidak pernah tentang satu angka ajaib — selalu tentang trade-off. Mengurangi buffer scrollback menghemat memori tetapi memangkas sejarah yang bisa kalian telusuri. Mematikan serialisasi mempercepat keluar session tetapi menghilangkan restore otomatis. Menyederhanakan tema meringankan renderer tetapi mengurangi kenyamanan visual. Setiap keputusan di episode ini adalah pilihan yang sadar antara kenyamanan dan sumber daya. Kalian yang memutuskan titik keseimbangannya, bukan Zellij.

#scroll_buffer_size: Kendalikan Memori Scrollback

Setiap pane Zellij menyimpan riwayat outputnya di memori agar kalian bisa scroll dan mencari tanpa batas — sampai batas tertentu. Opsi scroll_buffer_size menentukan berapa baris yang disimpan per pane. Nilai defaultnya adalah 10000 baris. Selama proses berjalan, angka ini dikalikan jumlah pane aktif menentukan beban memori.

Untuk menghitung dampak nyata, kalikan nilai ini dengan jumlah pane. Sepuluh pane dengan 10000 baris menyimpan potensi 100000 baris teks di memori. Jika kalian jarang scroll jauh ke belakang, buffer besar hanya membuang memori. Ingat juga bahwa baris yang panjang — misalnya output JSON yang belum dirapikan — menghabiskan lebih banyak memori per baris daripada baris pendek, jadi kebutuhan sebenarnya sangat bergantung pada jenis output yang kalian produksi.

options {
    scroll_buffer_size 3000
}

Kabar baiknya, pengaturan ini tidak memengaruhi buffer pane yang sudah berjalan sampai session di-restart. Setelah mengubah nilai, buka session baru agar diterapkan. Perlu diingat juga bahwa buffer yang kecil mempersempit ruang pencarian: fitur Scroll mode dan Search bekerja dalam batas buffer, jadi jika kalian sering mencari pola di output lama — katakanlah error yang muncul berjam-jam lalu — buffer yang terlalu kecil membuat pencarian itu mustahil. Pertimbangkan kebiasaan mencari kalian sebelum menurunkan angka ini.

#scrollback_lines_to_serialize: Restore yang Lebih Ringan

Ada opsi kedua yang sering tertukar dengan yang pertama: scrollback_lines_to_serialize. Keduanya sama-sama bicara soal scrollback, tetapi di titik yang berbeda. scroll_buffer_size mengatur memori runtime; scrollback_lines_to_serialize mengatur berapa baris scrollback yang ikut disimpan ketika session diserialisasi untuk di-restore.

Ketika kalian keluar dari session dengan serialisasi aktif, Zellij menyimpan layout dan sebagian isi pane agar bisa dibangun ulang nanti. Semakin banyak baris yang diserialisasi, semakin besar file yang ditulis ke disk dan semakin lambat proses save serta restore. Jika kalian tidak membutuhkan sejarah lengkap setelah restart — cukup layout dan command yang berjalan — nilai kecil sudah cukup.

options {
    scrollback_lines_to_serialize 500
}

Untuk alur kerja yang mengandalkan session persistence di mesin kecil, pasangan yang wajar adalah buffer runtime yang cukup untuk kerja harian dan nilai serialisasi yang kecil agar restore cepat. Kombinasi ini memberi kenyamanan scroll penuh saat kerja, tanpa beban disk dan waktu tunggu yang berlebihan saat kembali. Sebagai gambaran, nilai serialisasi yang terlalu besar bisa memperlambat pembukaan session secara terasa, terutama di mesin dengan disk mekanis atau media penyimpanan yang lambat.

#Tema Sederhana dan Beban Renderer

Zellij merender antarmukanya melalui plugin UI — tab-bar, status-bar, dan plugin lain — yang bekerja secara periodik. Beban renderer ditentukan oleh dua hal: seberapa sering plugin memperbarui diri, dan seberapa kompleks tampilan yang harus digambar. Tema dengan banyak lapisan warna, efek khusus, dan plugin dengan animasi terus-menerus akan lebih berat daripada tampilan yang sederhana.

Pada mesin terbatas, pengurangan beban renderer sering terasa sebagai kursor yang lebih responsif dan scrolling yang lebih mulus. Caranya: gunakan tema bawaan yang sederhana alih-alih tema custom yang berat, dan matikan plugin yang tidak benar-benar dipakai — setiap plugin yang dimuat berarti pekerjaan render tambahan.

options {
    theme "nord"
    simplified_ui true
}

simplified_ui mengurangi elemen UI yang ditampilkan, sehingga renderer punya lebih sedikit pekerjaan per frame. Tema nord dipilih karena paletnya sederhana dan tidak memerlukan banyak perhitungan gradasi. Di mesin yang sangat terbatas, bahkan memakai tema default tanpa modifikasi sudah membantu.

Ingat trade-off: fitur visual yang kalian nikmati — ikon animasi, theme switch otomatis, widget informatif — semuanya punya harga render. Di mesin kuat harga ini tak terasa; di mesin lemah, kalian harus memilih fitur mana yang sepadan. Salah satu ukuran yang paling berguna adalah jumlah plugin yang berjalan: setiap plugin UI menambahkan pekerjaan render yang berulang. Status-bar yang menampilkan banyak widget memperbarui dirinya setiap beberapa detik; jika kalian tidak pernah membaca sebagian besar widget tersebut, plugin itu adalah beban murni.

#Banyak Session dan Plugin: Tetap Responsif

Performa Zellij paling terasa saat jumlah session dan pane menumpuk. Setiap pane adalah proses shell yang berjalan, dan setiap session menambahkan beban pada server Zellij. Dua lusin session dengan masing-masing belasan pane akan terasa berbeda dari satu session rapi dengan tiga tab — bukan karena Zellij lambat, tetapi karena jumlah proses nyata yang harus dijaga.

Kebiasaan yang paling berdampak adalah disiplin: tutup pane yang sudah selesai, matikan session yang tidak dipakai, dan jangan membuka session baru tanpa tujuan. Sebelum menumpuk lebih banyak, lihat dulu apa yang sedang berjalan.

zellij list-sessions
zellij action dump-layout

zellij list-sessions menunjukkan semua session aktif — mengejutkan berapa banyak yang tersisa dari minggu lalu. zellij action dump-layout menampilkan isi session sehingga kalian bisa memutuskan mana yang layak dipertahankan. Matikan yang tidak terpakai dengan zellij kill-session.

Di luar jumlah session, perhatikan juga isi session: banyaknya tab dan pane per session adalah faktor kedua yang menentukan responsivitas. Dua pane yang saling bertukar output besar — misalnya satu pane menjalankan dev server dan pane lain mengikuti log-nya — akan terus memproses data selama keduanya hidup. Tidak ada yang salah dengan pola ini; yang penting kalian sadar bahwa setiap pane yang "memantau" adalah biaya CPU yang berkelanjutan.

Mouse juga ikut andil dalam konsumsi event: dengan mouse_mode menyala, Zellij memproses semua pergerakan pointer. Jika kalian bekerja keyboard-first, mematikan mouse mengurangi kerja event handling tanpa mengorbankan apa pun. Hal yang sama berlaku untuk serialisasi: menonaktifkan session_serialization menghilangkan kerja tulis disk saat keluar session, cocok untuk mesin dengan disk lambat.

Bedakan juga antara detach dan kill. Detach hanya memutus koneksi client — session, pane, dan proses di dalamnya terus berjalan dan menghabiskan sumber daya. Kill menghentikan semuanya. Jika kalian selesai dengan sebuah project dan tidak akan kembali dalam waktu dekat, detach bukan jawaban; zellij kill-session adalah. Kebiasaan kecil ini sendirilah yang paling sering membuat banyak session tetap ramping.

#Manajemen Sumber Daya di Mesin Terbatas

Semua knob di atas kalian pakai bersama untuk mesin dengan sumber daya terbatas — VPS 512 MB, laptop tua, atau container dengan batas ketat. Kuncinya bukan mematikan semua fitur, melainkan memilih kombinasi yang paling hemat tanpa kehilangan alur kerja inti.

options {
    scroll_buffer_size 6000
    scrollback_lines_to_serialize 1000
}

options {
    scroll_buffer_size 3000
    scrollback_lines_to_serialize 500
    simplified_ui true
}

Selain konfigurasi, terapkan kebiasaan operasional: batasi jumlah tab dan pane per session, hindari floating panes yang tidak perlu, dan jalankan hanya plugin yang esensial. Di mesin terbatas, satu session ramping jauh lebih nyaman daripada tiga session yang masing-masing membawa beban mati.

Ukur dulu dengan alat yang ada — htop untuk memori dan CPU, waktu yang terasa saat membuka session — baru putuskan knob mana yang paling layak diputar. Setiap mesin punya titik optimal yang berbeda. Di mesin yang sangat sempit, mulailah dari profil hemat pada code-group di atas, lalu longgarkan satu per satu hanya pada bagian yang benar-benar terasa kurang: jika scrollback terasa pendek, naikkan scroll_buffer_size; jika restore terasa lambat, turunkan scrollback_lines_to_serialize. Tuning yang disadari jauh lebih baik daripada mengikuti angka dari artikel orang lain.

#Kesalahan Umum (Common Pitfalls)

1. Menurunkan scroll_buffer_size terlalu agresif. Sejarah scrollback yang dibutuhkan hilang. Solusi: turunkan bertahap dan uji workflow scrolling serta pencarian setelah setiap perubahan.
2. Menyamakan scrollback_lines_to_serialize dengan buffer runtime. Dua dial berbeda untuk dua fase berbeda. Solusi: pahami bahwa satu mengatur memori live, yang lain mengatur data restore.
3. Menonaktifkan semua plugin sampai UI tidak berguna. Hemat berlebihan mengorbankan fungsi inti tab-bar dan status-bar. Solusi: kurangi plugin yang tidak dipakai, pertahankan yang esensial.
4. Mengukur performa tanpa baseline. Tidak tahu apakah perubahan benar-benar membantu. Solusi: catat kondisi awal dengan htop dan waktu buka session sebelum tuning.
5. Membiarkan puluhan session idle. Beban terus berjalan tanpa menghasilkan apa-apa. Solusi: audit dengan zellij list-sessions secara rutin dan matikan yang tidak terpakai.

#Penutup

Episode 24 menutup babak performance optimization dengan alat yang jelas: scroll_buffer_size untuk mengendalikan memori scrollback runtime, scrollback_lines_to_serialize untuk meringankan proses serialisasi dan restore, tema sederhana dan simplified_ui untuk mengurangi beban renderer, disiplin menjaga banyak session dan plugin tetap responsif, serta kombinasi tuning untuk mesin terbatas.

Poin yang harus kalian bawa:

• scroll_buffer_size mengatur memori live; scrollback_lines_to_serialize mengatur data restore — dua hal yang berbeda.
• Beban renderer turun dengan tema sederhana dan plugin yang lebih sedikit.
• Satu session per project, dan audit dengan zellij list-sessions secara rutin.
• Ubah satu variabel pada satu waktu, ukur dampaknya, baru lanjut.
• Mesin terbatas butuh trade-off yang sadar, bukan semua fitur sekaligus.

Performance bukan tentang angka tertinggi, tetapi tentang workspace yang tetap nyaman ketika sumber daya menipis. Dengan ini Fase 6 hampir selesai — episode 24 diikuti episode 25 yang memulai Fase 7: Fitur Stabil Terbaru (0.40 - 0.44) — menyusuri revolusi modern Zellij dari welcome screen dan filepicker 0.40, plugin manager 0.41, pinned floating panes dan theme spec 0.42, web client 0.43, hingga remote sessions, Windows support, dan CLI automation 0.44. Sampai jumpa di episode 25, dan biarkan Zellij kalian tetap ringan.