Swift, bahasa pengaturcaraan moden Apple, menghadapi kritikan yang semakin meningkat daripada pembangun berkenaan prestasi pemeriksa jenisnya. Perbincangan terkini dalam komuniti pembangun mengetengahkan kekecewaan meluas terhadap masa penyusunan yang boleh mencecah puluhan saat untuk ungkapan yang kelihatan mudah, menimbulkan persoalan tentang kesesuaian bahasa ini untuk pembangunan berskala besar.
Masalah Prestasi Yang Tidak Berkesudahan
Pembangun melaporkan mengalami kelewatan semakan jenis yang memberi kesan ketara terhadap produktiviti mereka. Satu contoh yang amat ketara melibatkan ungkapan penyambungan rentetan yang mudah yang dilaporkan mengambil masa 10 saat untuk disemak jenis dalam versi Swift terdahulu, dengan penambahbaikan hanya mengurangkannya kepada 6 saat dalam kemas kini terkini. Bagi pembangun yang bekerja pada perkakasan Apple moden seperti Mac M2, isu prestasi ini amat membimbangkan memandangkan perkakasan berkuasa yang tersedia.
Saya menjangkakan ungkapan seperti itu disemak jenis secara literal sejuta kali lebih pantas - paling kurang.
Isu teras berpunca daripada sistem semakan jenis berasaskan kekangan Swift, yang perlu mengemudi kombinasi kompleks operator terlebih muat dan inferens jenis. Dengan 17 muatan lebih operator + dan 9 jenis yang menerima pakai protokol ExpressibleByStringLiteral dalam pustaka piawai sahaja, pengkompil menghadapi kerumitan eksponen apabila menyelesaikan ungkapan asas.
Punca Utama Prestasi Lemah dalam Swift
- 17 overload operator
+dalam perpustakaan standard - 9 jenis yang menggunakan protokol
ExpressibleByStringLiteral - Kerumitan inferens jenis dua hala
- Penyelesaian overloading secara ad-hoc
Pilihan Seni Bina Diperiksa Semula
Dua ciri bahasa khusus muncul sebagai penyumbang utama kepada masalah prestasi: inferens jenis dua hala dan pemuatan lebih ad-hoc. Inferens dua hala membenarkan jenis mengalir kedua-dua arah ke atas dan ke bawah melalui pepohon ungkapan, manakala pemuatan lebih membolehkan berbilang fungsi berkongsi nama yang sama dengan jenis parameter berbeza. Walaupun ciri ini membolehkan sintaks Swift yang bersih dan ekspresif, ia datang dengan kos pengiraan yang signifikan.
Peta jalan pasukan Swift mengakui cabaran ini tetapi berhenti sejenak daripada mencadangkan penyelesaian radikal seperti membuang pemuatan lebih sepenuhnya, mengakui bahawa perubahan sedemikian akan memecahkan keserasian dengan pangkalan kod Swift sedia ada. Sebaliknya, mereka menumpukan pada penambahbaikan berperingkat kepada algoritma penyelesai kekangan dan sistem diagnostik.
Kesan Dunia Sebenar kepada Aliran Kerja Pembangunan
Isu prestasi mempunyai akibat praktikal untuk aliran kerja harian pembangun. Ramai melaporkan menghabiskan masa yang lama menunggu penyusunan hanya untuk menerima mesej ralat samar yang memberikan sedikit panduan untuk membaiki isu asas. Masalah ini menjadi lebih teruk dalam pembangunan SwiftUI, di mana hierarki paparan kompleks dan sintaks penutup susulan boleh mencipta mimpi ngeri semakan jenis.
Sesetengah pembangun telah menerima pakai amalan pengaturcaraan pertahanan untuk mengatasi batasan ini, termasuk anotasi jenis eksplisit di mana-mana dan mengelakkan rantaian operasi panjang. Walau bagaimanapun, penyelesaian ini menjejaskan matlamat Swift untuk menyediakan sintaks yang bersih dan mudah dibaca serta meletakkan beban tambahan ke atas pembangun untuk mengurus secara manual apa yang sepatutnya diautomasikan oleh pengkompil.
Penyelesaian Sementara Pembangun
- Anotasi jenis yang eksplisit untuk semua pembolehubah
- Mengelakkan pencampuran integer dan double tanpa casting eksplisit
- Memecahkan rantaian operasi yang panjang kepada pernyataan berasingan
- Meminimumkan penggunaan trailing closure dalam ungkapan yang kompleks
Tindak Balas Komuniti dan Platform Alternatif
Masalah prestasi berterusan telah menyebabkan sesetengah pembangun mempertimbangkan semula pilihan platform mereka. Kekecewaan ketara dalam perbincangan komuniti, dengan beberapa pengulas menyatakan keraguan tentang melabur lebih jauh dalam ekosistem Swift. Ada yang menyatakan kira-kira satu pertiga aplikasi App Store kini dibina menggunakan Flutter dan bukannya Swift asli, mencadangkan bahawa isu prestasi mungkin mendorong pembangun ke arah teknologi alternatif.
Keadaan ini juga menarik perbandingan kepada pendekatan Chris Lattner dengan Mojo, bahasa lebih baru yang mengambil arah seni bina berbeza untuk sistem jenisnya. Walaupun Swift terus berkembang, komuniti kelihatan terbahagi antara mereka yang sanggup bertolak ansur dengan batasan semasa dan mereka yang mencari penyelesaian lebih asas.
Peningkatan Prestasi Pemeriksaan Jenis Swift
- Swift 5.6: Pengoptimuman awal untuk penyelesai kekangan
- Swift 5.7: Pengurangan lanjut dalam masa pemeriksaan jenis (7s → 0.6s dalam sesetengah kes)
- Cawangan pembangunan: Penambahbaikan algoritma tambahan (turun ke 0.17s untuk ungkapan tertentu)
Melihat Ke Hadapan
Pasukan pembangunan Swift terus bekerja pada penambahbaikan, dengan versi terkini menunjukkan kemajuan boleh diukur. Swift 5.6 dan 5.7 telah menunjukkan peningkatan prestasi ketara dalam senario tertentu, dengan beberapa ungkapan kompleks mencatatkan masa semakan jenis dikurangkan dari 7 saat kepada 0.6 saat. Kerja berterusan menumpukan pada mengoptimumkan inferens disjungsi, mengendalikan penyelesaian separa dengan lebih cekap, dan menambah baik diagnostik mod suaka.
Walau bagaimanapun, ketegangan asas antara sintaks ekspresif Swift dan penyusunan berprestasi tinggi masih tidak diselesaikan. Semasa bahasa ini terus matang, mengimbangi keutamaan yang bersaing ini akan menjadi penting untuk mengekalkan kepuasan dan penerimaan pembangun. Komuniti memerhati dengan teliti, berharap bahawa kemas kini masa depan akan menyampaikan kedua-dua sintaks bersih yang mereka sukai dan prestasi yang mereka perlukan.
Nota: Semakan jenis berasaskan kekangan menggunakan sistem kekangan jenis yang mesti dipenuhi, sama seperti menyelesaikan teka-teki di mana setiap keping mesti mematuhi peraturan tertentu. Nota: Inferens jenis dua hala membolehkan pengkompil menyimpulkan jenis dengan menganalisis kedua-dua konteks di mana ungkapan digunakan dan komponen ungkapan.