Saya pikir tangkapan layar pengukuran produktivitas yang sudah ada ini sudah cukup untuk menyampaikan makna artikel, tetapi jika pembaca tertarik dengan pemikiran saya tentang hal ini, selamat datang.
Programmer terobsesi dengan kecepatan eksekusi program. Kami memantau kecepatan bahkan di mana kecepatan ini tidak terlalu penting. Terkadang bertentangan dengan akal sehat dan logika. Bahkan tidak sepenuhnya memahami apa arti kata "kecepatan" atau "kinerja" dalam setiap kasus. Kami masih menginginkan perangkat keras tercepat, bahasa tercepat, dan kerangka kerja paling ringan.
Saya rela percaya bahwa Anda, nama pengguna, tidak seperti itu. Bahwa Anda sendiri dapat menulis patokan yang tepat, Anda tahu cara kerja ini atau itu, Anda benci optimasi kecepatan hanya demi optimasi kecepatan dan Anda tahu banyak tentang perangkat keras. Tetapi ada lebih banyak orang dari paragraf sebelumnya. Diperiksa
Melihat contoh pada gambar di atas, saya pertama kali tersedak kopi ...
- Bagaimana naskah dapat bekerja lebih cepat daripada javascript, dan pada saat yang sama memakan memori beberapa kali lebih sedikit ?!
- Tidak mungkin!
Naskah tidak memiliki runtime sendiri. Artinya, Anda tidak dapat menjalankan naskah di mana saja atau hampir di mana saja. Anda pertama-tama harus mengompilasinya menjadi javascript, yang kemudian dijalankan dalam runtime, yang dipahami oleh javascript ini. Dalam hal ini, simpul v11.3434 bertindak sebagai runtime. Secara kebetulan senang, contoh javascript juga berjalan pada runtime yang sama.
Alih-alih membandingkan bahasa, kami mendapatkan kompetisi mikro dalam pemrograman olahraga.
→ kode naskah
→ kode javascript
Ternyata runtime, konsumsi memori, dan karakteristik lainnya sangat bergantung pada siapa yang menulis kode verifikasi ini dan caranya. Tentu saja, di sini Anda dapat menangkap argumen bahwa naskah memaksa Anda untuk menulis "kode yang tepat." Tapi tidak ada yang mengganggu untuk mengkompilasi naskah dalam javascript, dan saya juga tidak melihat tempat dengan optimasi.
Ngomong-ngomong, sudah berapa lama Anda melihat seseorang menulis kode yang serupa, dan harus melalui review? Padat, OOP dan FP tidak berbau di sini. Kode ini ditulis secara eksplisit dalam gaya prosedural. Karena dia punya tugas yang berbeda. Memahami dengan benar, meskipun kode memecahkan masalah, itu memerlukan refactoring sebelum produksi. Dan tidak diketahui bagaimana refactoring akan mempengaruhi kinerja. Tapi ini mungkin sebuah rewel.
Kami menemukan contoh. Jelas, contohnya tidak memadai.
Tapi mari kita lihat bagaimana bahasa pemrograman lain lulus tes yang sama.
Bagaimana menurut Anda, seberapa benarkah untuk menyimpulkan bahwa Swift lebih cepat daripada Go? Saya pikir itu salah. Cukup untuk melihat bahwa dua implementasi Rust (baris 2 dan 6) berbeda dalam waktu sebanyak 2 kali.
Dan di sini masalahnya sudah terlihat lebih serius. Jika membandingkan naskah dan javascript dilihat sebagai lelucon, maka dalam kasus bahasa lain, masalahnya tidak begitu jelas. Dan apakah Anda akan mulai memahami apa masalahnya jika Anda melihat laporan seperti itu?
Ternyata kode tolok ukur perlu dipantau secara ketat.
Pertanyaan: Kapan terakhir kali Anda melihat seseorang yang mencoba memeriksa ulang bagaimana kode benchmark ditulis tepat setelah Anda melihat grafik kinerja standar yang cantik?
Saya jarang bertemu ini. Saya pikir insinyur seperti itu semakin sedikit.
Di sisi lain, di depan mata saya ada banyak contoh ketika, berdasarkan tes seperti itu, kesimpulan dibuat tentang kinerja dan cahaya teknologi. Dan, omong-omong, opini publik sedang dibentuk.
Di sini Anda dapat membandingkan kinerja kerangka kerja javascript utama.
Apakah Anda masih percaya hasilnya? Saya tidak.
Itu saja. Tapi ada kabar baik. Keahlian programmer masih berpengaruh besar terhadap kinerja program.
Kesimpulan:
Microbenchmarks tidak akan menunjukkan kepada Anda apa pun kecuali Anda profesional dalam kinerja untuk platform tertentu. Lebih baik lagi, Anda sendiri menulis tolok ukur ini dengan mempertimbangkan dengan tepat persyaratan dan ketentuan Anda, sambil memahami apa yang Anda lakukan.
PS:
Posting ini ditulis sebagai jawaban untuk perbandingan tergesa-gesa dan kesimpulan tentang produktivitas masa depan. Tentu saja, semua kesimpulan dan argumen dari artikel dapat diberikan tanpa contoh ini, tetapi dengan angka dan spesifik lebih menyenangkan dan jelas.