Daftar Isi
Tren penggunaan kerangka kerja (framework) GUI bawaan berbasis bahasa pemrograman Rust untuk aplikasi desktop kini terus meningkat. Platform seperti Discord bahkan mengumumkan rencana pembuatan ulang aplikasinya menggunakan GPUI, sementara berbagai proyek aplikasi berbasis model bahasa besar (LLM) banyak memilih egui. Meski demikian, sebuah analisis teknis mendalam yang dilaporkan melalui blog.zortax.de menyoroti bahwa model status (state model) pada GPUI dan egui berpotensi menjadi jalan buntu untuk aplikasi desktop berskala rumit.
Masalah Pelacakan Perubahan dan Batasan Performa GPUI
GPUI mengidentifikasi dirinya sebagai kerangka kerja hibrid antara immediate mode dan retained mode yang menyimpan status di dalam entitas tertentu. Pembaruan status memerlukan notifikasi manual melalui fungsi notify yang membawa identitas entitas. Namun, mekanisme tersebut memiliki kemiripan dengan zone.js pada Angular karena GPUI tidak dapat mendeteksi bidang spesifik mana yang mengalami perubahan di dalam entitas tersebut. Akibatnya, GPUI cenderung merender ulang seluruh tampilan yang tidak berada di balik batas penempaan memori (caching).
Berdasarkan pengujian tolok ukur (benchmark) yang dipublikasikan di blog.zortax.de, pada antarmuka dengan 3.000 baris aktif yang menggunakan tampilan ter-cached per baris, perubahan pada satu label membutuhkan waktu 8,4 ms. Jika baris ditulis sebagai elemen biasa tanpa pembatas cache, waktu yang dibutuhkan membengkak hingga 92 ms. Penggunaan pemeriksaan kesetaraan data (equality guard) yang ditulis secara manual dapat menekan biaya penulisan ulang nilai dari 7,9 ms menjadi 0,9 µs, yang membuktikan tingginya beban eksekusi bawaan pada kerangka kerja tersebut.
Kecepatan pada editor Zed—aplikasi utama yang mempopulerkan GPUI—terjadi karena struktur antarmuka Zed masih tergolong sederhana. Tampilan Zed hanya terdiri dari beberapa tombol, bilah samping, serta editor teks yang dibuat sebagai elemen khusus yang memintas logika layout GPUI. Upaya optimasi melalui proyek cabang seperti gpui-fast milik Longbridge mampu menekan waktu eksekusi label 3.000 baris menjadi 3,4 ms. Namun, pada arsitektur data terbagi (shared model), pempertahanan tampilan (retention) justru dapat membuat durasi frame 11 persen lebih lambat.
Skalabilitas Arsitektur Elm dan Mode Immediate
Arsitektur berbasis Elm seperti yang digunakan pada Iced menawarkan kemudahan pada skala kecil melalui satu nilai status, satu pembaruan, dan satu tampilan. Meski begitu, pada aplikasi yang lebih kompleks, logika pembaruan data menjadi tersebar ke berbagai penangan pesan (message handlers). Sebagai gambaran, proyek aplikasi cosmic-files tercatat memiliki 136 varian pesan tingkat atas dan 73 varian pesan tambahan untuk tab antarmuka.
Dari sisi performa, pengujian Iced dengan 3.000 baris saat terjadi perubahan satu label mencatat pembentukan 39.023 widget dengan durasi 7,3 ms (atau 5,7 ms jika memanfaatkan fitur lazy). Sementara itu, egui yang mengusung mode immediate mengharuskan seluruh antarmuka dihitung ulang pada setiap frame tanpa memedulikan ada atau tidaknya perubahan. Pada pengujian 3.000 baris, suntingan kecil pada egui menghabiskan waktu sekitar 32 ms, atau 19 ms jika fitur aksesibilitas dinonaktifkan.
Reaktivitas Berbutir Halus dan Komponen Run-Once
Sebagai alternatif arsitektur, pendekatan reaktivitas berbutir halus (fine-grained reactivity) atau signals dinilai mampu memberikan kepastian mengenai bagian mana dari kode yang perlu dijalankan kembali saat terjadi perubahan status. Melalui kerangka kerja eksperimental zgui, pengisian perubahan label pada 3.000 baris hanya memakan waktu 0,69 ms, atau sekitar 12 kali lebih cepat dibanding GPUI.
Model komponen run-once—tempat badan komponen hanya dieksekusi satu kali dan fungsi penutup (closure) mengamati perubahan data—dinilai menjadi struktur API paling sederhana untuk mendukung presisi tersebut. Walaupun demikian, pendekatan reaktivitas halus ini tetap memiliki kelemahan, seperti biaya alokasi memori awal yang lebih tinggi saat pembuatan grafik dependensi. Pengujian penyaringan 3.000 baris menunjukkan Iced memerlukan waktu 56 ms, egui 67 ms, dan GPUI 123 ms, sedangkan kerangka berbasis reaktivitas halus seperti zgui membutuhkan 371 ms dan Floem mencapai 835 ms.
Seluruh data pengujian tersebut dihimpun menggunakan perangkat keras berpesifikasi prosesor Intel i9-13900K, kartu grafis RTX 3080 Ti, serta lingkungan sistem operasi Linux dengan Vulkan API.
Sumber: Hacker News: Front Page
