Swift, bahasa pemrograman modern Apple, menghadapi kritik yang semakin meningkat dari para pengembang terkait performa type checker-nya. Diskusi terkini di komunitas pengembang menyoroti frustrasi yang meluas dengan waktu kompilasi yang dapat mencapai puluhan detik untuk ekspresi yang tampaknya sederhana, memunculkan pertanyaan tentang kesesuaian bahasa ini untuk pengembangan skala besar.
Masalah Performa yang Tak Kunjung Hilang
Para pengembang melaporkan mengalami penundaan pengecekan tipe yang secara signifikan mempengaruhi produktivitas mereka. Salah satu contoh yang cukup mencengangkan melibatkan ekspresi penggabungan string yang sederhana yang dilaporkan membutuhkan waktu 10 detik untuk type-check di versi Swift sebelumnya, dengan perbaikan hanya mengurangi ini menjadi 6 detik dalam pembaruan terkini. Bagi pengembang yang bekerja di perangkat keras Apple modern seperti Mac M2, masalah performa ini sangat mengkhawatirkan mengingat perangkat keras yang tersedia sangat kuat.
Saya berharap ekspresi seperti itu dapat melakukan type-check lebih cepat sejuta kali - setidaknya.
Masalah intinya berasal dari sistem pengecekan tipe berbasis constraint Swift, yang harus menavigasi kombinasi kompleks dari operator yang kelebihan beban dan inferensi tipe. Dengan 17 overload dari operator + dan 9 tipe yang mengadopsi protokol ExpressibleByStringLiteral dalam standard library saja, kompiler menghadapi kompleksitas eksponensial ketika menyelesaikan bahkan ekspresi dasar.
Penyebab Utama Masalah Performa di Swift
- 17 overload operator
+dalam pustaka standar - 9 tipe yang mengadopsi protokol
ExpressibleByStringLiteral - Kompleksitas inferensi tipe bidireksional
- Resolusi overloading ad-hoc
Pilihan Arsitektur Diperiksa Ulang
Dua fitur bahasa tertentu tampaknya menjadi penyumbang utama masalah performa: inferensi tipe bidirectional dan overloading ad-hoc. Inferensi bidirectional memungkinkan tipe mengalir baik ke atas maupun ke bawah melalui pohon ekspresi, sementara overloading memungkinkan beberapa fungsi berbagi nama yang sama dengan tipe parameter yang berbeda. Meskipun fitur-fitur ini memungkinkan sintaks Swift yang bersih dan ekspresif, mereka datang dengan biaya komputasi yang signifikan.
Roadmap tim Swift mengakui tantangan ini tetapi berhenti sebelum mengusulkan solusi radikal seperti menghapus overloading sepenuhnya, mengakui bahwa perubahan seperti itu akan memecah kompatibilitas dengan basis kode Swift yang ada. Sebagai gantinya, mereka fokus pada perbaikan bertahap pada algoritma constraint solver dan sistem diagnostik.
Dampak Nyata pada Alur Kerja Pengembangan
Masalah performa memiliki konsekuensi praktis untuk alur kerja harian pengembang. Banyak yang melaporkan menghabiskan waktu signifikan menunggu kompilasi hanya untuk menerima pesan error yang membingungkan yang memberikan sedikit panduan untuk memperbaiki masalah yang mendasarinya. Masalah ini menjadi sangat akut dalam pengembangan SwiftUI, di mana hierarki tampilan yang kompleks dan sintaks trailing closure dapat menciptakan mimpi buruk pengecekan tipe.
Beberapa pengembang telah mengadopsi praktik pemrograman defensif untuk mengatasi keterbatasan ini, termasuk anotasi tipe eksplisit di mana-mana dan menghindari rantai operasi yang panjang. Namun, solusi ini merusak tujuan Swift untuk menyediakan sintaks yang bersih dan mudah dibaca serta memberikan beban tambahan pada pengembang untuk secara manual mengelola apa yang seharusnya diotomatiskan oleh kompiler.
Solusi Sementara Developer
- Anotasi tipe eksplisit untuk semua variabel
- Menghindari pencampuran integer dan double tanpa casting eksplisit
- Memecah rantai operasi panjang menjadi pernyataan terpisah
- Meminimalkan penggunaan trailing closure dalam ekspresi kompleks
Tanggapan Komunitas dan Platform Alternatif
Masalah performa yang terus-menerus telah membuat beberapa pengembang mempertimbangkan kembali pilihan platform mereka. Frustrasi terasa jelas dalam diskusi komunitas, dengan beberapa komentator mengungkapkan keraguan tentang berinvestasi lebih jauh di ekosistem Swift. Beberapa mencatat bahwa sekitar sepertiga aplikasi App Store sekarang dibangun menggunakan Flutter daripada Swift native, menunjukkan bahwa masalah performa mungkin mendorong pengembang ke arah teknologi alternatif.
Situasi ini juga menarik perbandingan dengan pendekatan Chris Lattner dengan Mojo, bahasa yang lebih baru yang mengambil arah arsitektur yang berbeda untuk sistem tipenya. Sementara Swift terus berkembang, komunitas tampak terbagi antara mereka yang bersedia mentolerir keterbatasan saat ini dan mereka yang mencari solusi yang lebih mendasar.
Peningkatan Performa Type Checking Swift
- Swift 5.6: Optimasi awal untuk constraint solver
- Swift 5.7: Pengurangan lebih lanjut dalam waktu type checking (7 detik → 0,6 detik dalam beberapa kasus)
- Development branch: Peningkatan algoritma tambahan (turun hingga 0,17 detik untuk ekspresi tertentu)
Melihat ke Depan
Tim pengembangan Swift terus mengerjakan perbaikan, dengan versi terkini menunjukkan kemajuan yang terukur. Swift 5.6 dan 5.7 telah menunjukkan peningkatan performa yang signifikan dalam skenario tertentu, dengan beberapa ekspresi kompleks melihat waktu pengecekan tipe berkurang dari 7 detik menjadi 0,6 detik. Pekerjaan yang sedang berlangsung berfokus pada mengoptimalkan inferensi disjungsi, menangani solusi parsial dengan lebih efisien, dan meningkatkan diagnostik mode refuge.
Namun, ketegangan mendasar antara sintaks ekspresif Swift dan kompilasi yang performan masih belum terselesaikan. Seiring bahasa ini terus matang, menyeimbangkan prioritas yang bersaing ini akan sangat penting untuk mempertahankan kepuasan dan adopsi pengembang. Komunitas memperhatikan dengan cermat, berharap bahwa pembaruan di masa depan akan memberikan sintaks bersih yang mereka sukai dan performa yang mereka butuhkan.
Catatan: Constraint-based type checking menggunakan sistem constraint tipe yang harus dipenuhi, mirip dengan memecahkan teka-teki di mana setiap bagian harus sesuai dengan aturan tertentu. Catatan: Bidirectional type inference memungkinkan kompiler untuk menyimpulkan tipe dengan menganalisis kedua konteks di mana ekspresi digunakan dan komponen ekspresi.
Referensi: Roadmap for improving the type checker