Bagi para pengguna ekosistem Arch Linux, Arch User Repository (AUR) adalah nyawa kedua setelah repositori resmi. Mengompilasi paket dari source code secara lokal seringkali menuntut waktu dan sumber daya komputasi yang tidak sedikit. Di bulan Juni 2026 ini, komunitas disuguhkan persaingan sengit antara dua antarmuka manajer paket yang sangat populer: Shelly dan Octopi. Keduanya punya cara kerja yang sama sekali berbeda di balik kap mesinnya.
Tulisan ini akan membedah secara spesifik khusus pada aspek performa AUR dari kedua perangkat lunak tersebut. Kita akan melihat bagaimana arsitektur terbaru, adaptasi teknologi terkini, serta umpan balik langsung dari para pengguna garis keras, khususnya di forum komunitas CachyOS, menentukan siapa yang paling layak memonopoli pengelolaan paket di sistem operasi kesayanganmu.

Ringkasan Eksekutif: Peta Kekuatan
| Aspek Performa AUR | Shelly | Octopi | Pemenang |
|---|---|---|---|
| Arsitektur Dasar | Native libalpm (bukan *wrapper) | Qt wrapper + parsing output pacman | Shelly |
| Kecepatan Pencarian AUR | Cepat & responsif | Cukup cepat, tapi kadang terasa lambat | Shelly |
| Kecepatan Build & Install | Lebih cepat (optimasi MemoryPack di v2.3+) | Sedang, kadang lambat saat proses panjang | Shelly |
| Penggunaan Resource | Lebih efisien CPU & RAM | Lebih boros (Qt + proses *parsing) | Shelly |
| Stabilitas Build Besar | Lebih stabil dan konsisten | Kadang lock up / freeze mendadak | Shelly |
| Penanganan Dependency | Baik (sempat ada catatan di awal rilis) | Sangat baik & transparan | Octopi (sedikit unggul) |
| Pengalaman Keseluruhan | Terasa lebih modern & ringan ditarik | Fungsional tapi terasa "berat" di beberapa case | Shelly |
Membongkar Mesin: Penjelasan Detail Arsitektur
Mengapa ada perbedaan yang begitu mencolok? Jawabannya terletak pada fondasi kode yang membangun mereka.
1. Fondasi Arsitektur: Native vs Wrapper
Di sudut merah, Shelly mengambil jalur berani dengan dibangun menggunakan pendekatan native libalpm. Artinya, ia "berbicara" langsung dengan pustaka inti pacman tanpa perantara. Tidak ada proses membaca output teks terminal secara manual. Di sudut biru, Octopi bertindak lebih sebagai wrapper. Ia mengeksekusi perintah pacman atau AUR helper di latar belakang, lalu membaca dan menerjemahkan teks output tersebut (parsing) ke dalam antarmuka Qt. Secara logis, pendekatan wrapper ini memakan siklus kerja prosesor yang lebih panjang.
2. Responsivitas Pencarian dan Refresh AUR
Ketika kamu mencari sebuah paket langka di AUR, waktu adalah segalanya. Shelly membuktikan diri lebih cepat dan responsif. Lompatan performa ini semakin terasa setelah pembaruan versi 2.3 yang cerdik, di mana mereka meninggalkan format pembacaan JSON yang lambat dan beralih ke MemoryPack. Sebaliknya, pengguna Octopi sering mengeluhkan antarmuka yang mendadak lock up (membeku sementara) saat melakukan refresh mirror yang sedang mengalami latensi tinggi.
3. Kecepatan Eksekusi Build & Install
Proses menyusun (build) kode sumber dari AUR menguras tenaga komputer. Shelly secara konsisten menunjukkan performa terbaiknya di sini berkat komunikasi bebas hambatan dengan libalpm. Proses kompilasi paket-paket raksasa berlalu lebih lancar. Tidak heran jika tim distribusi CachyOS secara resmi memensiunkan Octopi dan menggantinya dengan Shelly sebagai alat bawaan sistem mereka demi memaksimalkan kecepatan rute kompilasi ini.
4. Konsumsi Sumber Daya Komputasi
Arsitektur modern GTK 4 milik Shelly dirancang untuk efisiensi tinggi, memakan RAM dan CPU yang jauh lebih rendah selama mode siaga maupun saat bekerja keras. Sementara itu, kerangka kerja Qt milik Octopi, ditambah beban kerja menerjemahkan teks terminal terus-menerus, membuatnya lebih boros sumber daya.
5. Transparansi Penanganan Dependency
Satu-satunya benteng pertahanan yang masih dikuasai Octopi dengan brilian adalah transparansi. Bagi para sysadmin yang paranoid, Octopi membeberkan secara blak-blakan dependensi apa saja yang akan dipasang. Di awal pengembangannya, Shelly sempat mendapat kritik keras di forum karena mengategorikan dependensi kompilasi (make dependencies) sebagai paket eksplisit. Walaupun cacat logika ini sudah banyak ditambal pada pembaruan terkini, kedisiplinan Octopi dalam hal transparansi belum bisa diremehkan.
Kesimpulan: Mana yang Harus Dipilih?
- Jika prioritas utamamu adalah kecepatan mentah, efisiensi memori, dan kelancaran proses AUR yang masif, maka Shelly adalah jawaban mutlak berkat mesin native libalpm dan MemoryPack-nya.
- Jika kamu kebetulan menggunakan CachyOS, tidak ada alasan untuk melirik yang lain karena Shelly sudah dikonfigurasi dan dioptimasi secara default oleh pengembangnya.
- Namun, jika kamu memiliki trust issue dan ingin melihat setiap detail baris perintah secara telanjang layaknya membaca terminal, Octopi tetap menjadi teman lama yang setia.
Catatan tambahan: Performa kompilasi di dunia nyata juga akan dipengaruhi oleh mesin penggerak AUR helper di balik layar (seperti paru atau *yay). Keduanya menggunakan asisten yang sama, namun efisiensi cara mereka memberikan instruksi lah yang melahirkan perbedaan signifikan ini.