Pasukan TypeScript telah membuat keputusan mengejutkan yang menarik perhatian pembangun JavaScript di seluruh dunia. Walaupun amalan terbaik moden mengutamakan pengisytiharan const dan let, pangkalan kod pengkompil TypeScript telah sengaja dipenuhi dengan kenyataan var gaya lama. Pilihan ini telah mencetuskan perbincangan sengit mengenai prestasi enjin JavaScript dan kos tersembunyi ciri bahasa moden.
Keputusan ini berpunca daripada penemuan penting yang dibuat semasa peralihan TypeScript daripada sasaran output ES5 kepada ES2018. Apabila pasukan menaik taraf untuk menggunakan sintaks let dan const asli daripada mentranspil kepada var, mereka menjangkakan prestasi yang lebih baik. Sebaliknya, mereka menghadapi kelembapan yang tidak dijangka yang menyebabkan mereka menyiasat punca masalah.
Masalah Prestasi Temporal Dead Zone
Punca masalah prestasi adalah sesuatu yang dipanggil Temporal Dead Zone (TDZ). Ciri ini, yang diperkenalkan dengan let dan const, menghalang pembangun daripada mengakses pemboleh ubah sebelum ia dimulakan, melemparkan ReferenceError daripada mengembalikan undefined seperti yang dilakukan oleh var. Walaupun tingkah laku ini menangkap pepijat dan menjadikan kod lebih boleh diramal, ia datang dengan kos tersembunyi.
Enjin JavaScript mesti melakukan pemeriksaan masa jalan untuk menentukan sama ada pemboleh ubah berada dalam TDZ nya. Tidak seperti pengisytiharan var yang hanya diangkat dan dimulakan dengan undefined, let dan const memerlukan enjin untuk menjejaki keadaan permulaan setiap pemboleh ubah sepanjang pelaksanaan. Penjejakan ini menjadi sangat mahal apabila pemboleh ubah ditangkap dalam penutupan atau digunakan dalam senario skop yang kompleks.
Kesan prestasi terbukti besar untuk pangkalan kod TypeScript . Selepas memindahkan sebahagian besar pengisytiharan let dan const mereka kembali kepada var, pasukan memerhati peningkatan prestasi 8% merentas pelbagai penanda aras. Penemuan ini mencabar andaian bahawa ciri JavaScript yang lebih baru sentiasa lebih baik dari sudut prestasi.
Perbandingan Prestasi
| Jenis Deklarasi | Tingkah Laku Hoisting | Pemeriksaan TDZ Diperlukan | Kesan Prestasi |
|---|---|---|---|
var |
Hoisted, dimulakan dengan undefined |
Tidak | Prestasi asas |
let/const |
Hoisted, tetapi tidak dimulakan | Ya | 8% lebih perlahan dalam penanda aras TypeScript |
Prestasi TDZ Enjin JavaScript
- V8 ( Chrome , Node.js , Deno ): Overhed TDZ yang boleh diukur diperhatikan
- JavaScriptCore ( Safari ): Berpotensi pengendalian TDZ yang lebih cekap
- Usaha pengoptimuman: Analisis statik untuk menghapuskan pemeriksaan TDZ yang tidak perlu dalam pembangunan
Respons Komuniti dan Perbezaan Enjin
Pendedahan ini telah menjana perbincangan ketara di kalangan pembangun dan penyelenggara enjin JavaScript . Beberapa ahli komuniti telah bekerja pada pengoptimuman untuk mengurangkan overhed TDZ melalui teknik analisis yang lebih bijak. Pengoptimuman ini boleh menghapuskan pemeriksaan TDZ dalam kes di mana analisis statik membuktikan pemboleh ubah tidak akan diakses sebelum permulaan.
Menariknya, penalti prestasi nampaknya berbeza antara enjin JavaScript . Walaupun V8 (digunakan dalam Chrome , Node.js , dan Deno ) menunjukkan overhed TDZ yang boleh diukur, enjin lain seperti JavaScriptCore mungkin mengendalikan pemeriksaan ini dengan lebih cekap. Ketidakkonsistenan ini menyerlahkan hubungan kompleks antara spesifikasi bahasa dan butiran pelaksanaan enjin.
Pengkompil Scala.js menghadapi cabaran serupa dan juga lalai untuk mengeluarkan pengisytiharan var atas sebab prestasi, walaupun ketika menyasarkan versi ECMAScript moden. Ini menunjukkan masalah prestasi TDZ melangkaui pengkompil TypeScript sahaja dan mempengaruhi alat lain yang mengutamakan kelajuan pelaksanaan.
Implikasi Lebih Luas untuk Pembangunan JavaScript
Situasi ini menimbulkan persoalan penting mengenai pertukaran antara ciri keselamatan bahasa dan prestasi. Walaupun TDZ membantu mencegah ralat pengaturcaraan biasa, kos masa jalannya mungkin cukup ketara untuk penting dalam aplikasi kritikal prestasi. Perdebatan mencerminkan ketegangan yang lebih luas dalam reka bentuk bahasa antara pengalaman pembangun dan kecekapan pelaksanaan.
Saya sangat gembira kerana saya tidak perlu menggunakan var lagi. Dan untuk TypeScript , saya pasti ia hanya satu lagi sebab untuk memindahkan pangkalan kod mereka ke Go .
Bagi kebanyakan pembangun, pilihan antara var, let, dan const masih harus berdasarkan kejelasan kod dan ketepatan daripada kebimbangan prestasi. Pengkompil TypeScript mewakili kes luar biasa di mana kelajuan pelaksanaan cukup kritikal untuk membenarkan mengorbankan beberapa faedah bahasa moden. Walau bagaimanapun, penemuan ini berfungsi sebagai peringatan berharga bahawa ciri bahasa yang lebih baru tidak sentiasa lebih pantas, dan pertimbangan prestasi kadangkala memerlukan kompromi yang sukar.
Kerja berterusan untuk mengoptimumkan pemeriksaan TDZ dalam enjin JavaScript mungkin akhirnya menjadikan pertukaran ini tidak perlu. Sehingga itu, keputusan pasukan TypeScript menunjukkan kepentingan mengukur kesan prestasi apabila menggunakan ciri bahasa baru, terutamanya dalam pangkalan kod sensitif prestasi.
Rujukan: The Temporal Dead Zone, or why the TypeScript codebase is littered with var statements