pek jaring

Ini akan menjadi catatan pendek... tetapi semoga dengan yang lebih panjang susulan.

Semasa percutian musim sejuk saya, saya mendapat sedikit masa untuk melakukan satu percubaan:

Bolehkah perkakas web yang dibuat menggunakan C#/.NET menghasilkan prestasi yang setanding dengan Rust / Go / Zig ...?

Jadi saya melakukan beberapa pengekodan... (yang boleh anda temui di GitHub)

Proses

Saya bermula dengan logik pengikat kasar:

• Buka fail
• Baca kandungan mereka
• Gunakan ungkapan biasa untuk mengesan, mis., import pernyataan dalam fail JS
• Selesaikan modul terpaut
• Buka fail package.json yang diselesaikan / sedia ada untuk mengenal pasti laluan modul

Hasilnya adalah mudah: Menggunakan AoT (kompilasi lebih awal) .NET pastinya boleh digunakan untuk projek web yang berprestasi tinggi.

Jadi saya meneruskan sedikit percubaan; menggantikan ungkapan biasa dengan pemahaman kod sebenar.

TLDR; Keputusan

Jawapannya ialah: ya! ?

Pengikat pada masa ini ciri-tidak lengkap, tetapi hasil pertama agak kukuh. Penanda aras yang ditunjukkan dalam README menunjukkan bahawa prestasi pastinya berada di tempat yang sama seperti alat lain. Cukup pantas.

Lagi Butiran

Secara peribadi, saya berpendapat bahawa C#/.NET jauh lebih rumit daripada Rust dan lebih berkuasa daripada Go. Ia datang dengan beberapa kelemahan juga - tidak akan berbohong.

Sebab utama mengapa C#/.NET boleh berdaya maju dalam ruang itu ialah AoT. Tanpa AoT prestasi permulaan (serta keperluan masa jalan) membunuh keseluruhan idea.

AoT, sebaliknya, datang dengan beberapa cabaran. Sesetengah perpustakaan tidak boleh digunakan atau memerlukan beberapa kerja untuk disepadukan. Oleh itu, beberapa fleksibiliti .NET tidak boleh digunakan.

Untuk projek ujian terbesar yang juga digunakan oleh alat seperti rspack kami mendapat keputusan ini:

Perhatikan bahawa walaupun pengikat adalah ciri yang tidak lengkap, ia cukup direka untuk menghasilkan hasil yang sah pada projek. Jadi, walaupun semua keputusan pada masa ini adalah awal, sekurang-kurangnya ada kesahihan padanya.

Test	esbuild	rspack	Vite	pek jaring
Small lib	326ms	611ms	601ms	359ms
Small project	670ms	912ms	1658ms	418ms
Medium project	1931ms	2877ms	10601ms	974ms
Large project	2189ms	2422ms	13710ms	1357ms

Jadi ya, pek jaring sudah mengalahkan saingan malah mempunyai potensi untuk prestasi yang lebih baik. Walaupun ia boleh dioptimumkan lagi, ia juga akan kehilangan beberapa prestasi apabila perkara seperti peta sumber atau gegaran pokok diperkenalkan. Pada masa ini saya yakin bahawa secara keseluruhannya ia sepatutnya hampir sama seperti sekarang disebabkan oleh potensi pengoptimuman (seperti penstriman dalam generasi AST JS).

Halangan terbesar pada masa ini ialah ia hanya menyokong JS(X) - belum ada TypeScript (ia cuba menghuraikan fail ini, tetapi apabila jenis digunakan ia akan gagal). Ia akan menjadi "agak" mudah untuk disokong, tetapi saya perlu menolak Acornima untuk itu dan itu adalah sesuatu yang saya hanya akan lakukan jika terdapat buzz yang mencukupi di sekitar projek itu.

Tinjauan

Terdapat banyak lagi perkara yang menarik untuk dibincangkan. Beberapa asas perlu dibersihkan terlebih dahulu. Perkara seperti peta sumber, sokongan TypeScript atau mungkin sistem konfigurasi adalah bagus.

Terdapat beberapa perkara dalam percubaan ini yang tidak dilakukan oleh pengikat lain. Sebagai contoh, jika titik masuk HTML anda mempunyai peta import, maka entri dalam peta import secara automatik diambil sebagai luaran. Begitu juga, anda boleh menetapkan kebergantungan tertentu sebagai dikongsi - dalam kes ini terdapat entri peta import / peta import yang dibuat secara automatik dalam HTML yang terhasil. Agak kemas.

Pada masa hadapan, pengikat akan mempunyai sokongan asli (iaitu, luar kotak) untuk SASS, modul CSS, CSS-in-JS, serta persekutuan modul dan persekutuan asli.

Apakah pendapat anda? Adakah anda fikir ini idea yang berdaya maju atau hanya sampah? Adakah pengikat asli .NET yang pantas dengan lalai yang wajar sesuatu yang kita perlukan?

Atas ialah kandungan terperinci pek jaring. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!