Sebutan yang akurat untuk para pengguna bahasa pemrograman Rust yang tergila-gila pada performance. Memang secara desain, bahasa Rust itu sudah blazing fast sejak lahir — sehingga membuat para developernya merasa superior dibanding pengguna bahasa-bahasa pemrograman “mayoritas” lainnya.

Sebetulnya, performance itu bukan segalanya. Terkadang suatu software hanya perlu menjadi “cukup cepat” dibanding “sangat cepat”. Apakah user akan notice perbedaan kecepatan 0.20 ms dan 0.01 ms? Mungkin tidak. Jadi, menghabiskan waktu untuk membuat algoritmanya 20x lebih cepat itu tidak selalu worth it. Selalu ingat principle YAGNI (You aren’t gonna need it) — kita ga perlu menambahkan sesuatu sebelum kita benar-benar membutuhkannya.

Dalam software engineering, definisi “cukup cepat” ini tergantung dari requirement user. Mungkin jika ingin membuat high-performance trading platform atau real-time data processing system, kita harus memprioritaskan performance pada pertama kali mendesain systemnya. Tapi jika tidak, sebuah aplikasi CMS yang fitur-fiturnya mayoritas hanya CRUD tidak membutuhkan proses insert data secepat kilat 0.01 ms — dengan 0.50 ms juga sudah cukup cepat kok.

Akan selalu ada tradeoff yang terjadi dalam software development: scalability vs cost, security vs usability, dan yang akan kita bahas disini adalah performance vs maintainability. Code yang sangat dioptimalkan buat naikin performancenya biasanya akan mengorbankan readability dan simplicity. Alih-alih mengubah algoritma menjadi lebih optimized, malah bikin codenya jadi lebih ruwet.

Jadi, kapan kita harus mulai mikirin performancenya?

Selalu ingat sebuah quote legendaris dari buku The Art of Computer Programming oleh Donald Knuth:

Premature optimization is the root of all evil.

Bayangin aja, baru mau bangun startup tapi udah mikirin gimana aplikasi ini bisa ngehandle satu juta concurrent user. Ini memang masalah yang valid untuk dipikirin, tapi ga sedini itu untuk dipikirin. Sebelum mikirin yang lebih jauh, coba pikirin dulu gimana cara aplikasinya bisa membuat 100 orang puas menggunakannya.

Gw sering menemukan developer yang mengalami analysis paralysis — overthinking tentang gimana aplikasinya harus bisa ngehandle jutaan user, berapa banyak microservices yang harus dipecah, dan mereka kira design system harus perfect dari awal development. Hal ini harus dihindari

Jadi, sebenarnya kecepatan itu adalah hal paling terakhir yang kita bisa pikirin setelah yang lainnya tercapai. Dalam dunia software engineering, urutan yang dilakukan adalah: get it right, get it beautiful, lalu get it fast.

Step pertama itu get it right — memastikan semua work sesuai ekspektasi. Ga perlu ambil pusing buat mikirin kerapian atau estetika kodingan, yang penting codenya bisa jalan.

Step kedua, get it beautiful — buatlah code itu menjadi lebih readable dan serapi mungkin. Ingat, yang paling utama yaitu readability. Kalau lambat tapi readable, mudah untuk difix — tapi kalo baca codenya aja kesusahan, gimana cara ngefixnya?

Step ketiga, get it fast — setelah codenya berjalan dengan benar dan mudah dibaca, barulah kita bisa mulai memikirkan performance. Sebelum kita nuduh suatu bagian code sebagai sumber masalah, kita harus melakukan profiling terlebih dahulu. Profiling adalah kegiatan untuk mengidentifikasi bottleneck yang sebenarnya. Jangan asal mengoptimasi tanpa data, karena bisa jadi kita malah menghabiskan waktu untuk mengoptimasi bagian yang gak signifikan terhadap performa. Time wasted.

Profiling akan menunjukkan di mana sebenarnya aplikasi kita menghabiskan waktu paling banyak. Mungkin kita mengira database query yang jadi masalah, tapi ternyata rendering template yang menjadi bottleneck — atau kita pikir algoritma sortingnya yang lambat, padahal network latency yang menjadi penyebab utama.

Selain melakukan profiling, kita juga dapat melakukan benchmarking dan monitoring. Benchmarking adalah kegiatan mengukur performa dari sebuah code/function/fitur. Setiap bahasa pemrograman ada fitur benchmark test, seperti testing.B pada Golang, criterion pada Rust. Sementara monitoring berguna untuk memantau indikator-indikator penting, seperti response time, throughput, latency, error rates, dan resource utilization,

Kesimpulan

• Good developers menulis code yang efisien. Tapi great developers tau kapan harus mengorbankan efisiensi dan performance untuk readability yang lebih baik.
• Kalau lu adalah seorang experienced developer yang lagi ngerjain task simpel, biasanya bisa langsung paham gimana cara membuat code yang right, beautiful, dan fast dalam sekali lihat.
• Optimisasi itu bukan kegiatan yang cuma dilakukan sekali, tapi iteratif dan dilakukan secara berkala.