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 taringnya 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.