Apakah kinerja bahasa pemrograman yang lebih lambat, sungguh, hal yang buruk? [Tutup]

Begini cara saya melihatnya.

Ada kode mesin dan itu semua yang dibutuhkan komputer untuk menjalankan sesuatu. Komputer tidak peduli tentang bahasa pemrograman. Tidak masalah bagi mereka apakah kode mesin berasal dari Perl, Python atau PHP. Bahasa pemrograman tidak melayani komputer. Mereka melayani programmer.

Beberapa bahasa pemrograman berjalan lebih lambat daripada yang lain tetapi itu tidak selalu karena ada sesuatu yang salah dengan mereka. Dalam banyak kasus, itu karena mereka melakukan lebih banyak hal yang seharusnya dilakukan oleh programmer (yaitu manajemen memori) dan dengan melakukan hal-hal ini, mereka lebih baik dalam apa yang seharusnya mereka lakukan - melayani programmer.

Jadi, apakah kinerja lebih lambat, bahasa pemrograman, sungguh, hal yang buruk?

Saya tidak berpikir itu otomatis buruk. Python lebih lambat dari C ++, tetapi ketika keduanya cukup cepat , Python mungkin menjadi pilihan terbaik untuk masalah yang dihadapi bahkan jika lebih lambat .

Itu selalu merupakan tradeoff. Untuk tugas kecil satu kali, jauh lebih cepat untuk menulis skrip Python daripada aplikasi C ++ yang melakukan hal yang sama (contoh khas bagi saya adalah semacam pemrosesan teks batch atau berjalan di pohon direktori dan melakukan sesuatu ke file), dan saya tidak terlalu peduli apakah itu membutuhkan 10 ms atau 1000 ms, walaupun 100x lebih lambat, karena mungkin saya butuh separuh waktu untuk menulis dan menguji.

Tentu saja, alangkah baiknya jika Python secepat C ++, jadi dalam pengertian itu saya setuju dengan pernyataan Anda bahwa "lambat = buruk". Tapi kemudian saya lebih suka bahasa yang kuat yang berjalan secepat yang saya inginkan dengan tidak melakukan beberapa hal (katakanlah, array batas memeriksa array mentah) selama itu memungkinkan saya untuk memutuskan kapan harus melakukan tradeoff itu (katakanlah, dengan menggunakan std: : vektor).

Cukup sederhana - menjadi lambat adalah hal yang buruk

ketika program membutuhkan tingkat kinerja tertentu

karena tanpa kinerja itu Anda tidak memenuhi persyaratan.

Ini bisa berupa apa saja dari aplikasi bisnis yang perlu memproses kueri dalam jumlah waktu yang dapat diterima hingga permainan yang perlu menampilkan banyak informasi di layar kapan saja. Jika programnya tidak cukup cepat, maka itu tidak berfungsi .

Lihatlah seperti ini: komputer itu bodoh . Mereka dengan patuh mengikuti instruksi yang bisa diikuti oleh orang bodoh mana pun dengan tabel trigonometri. Mereka bersikeras untuk melakukan apa yang Anda katakan, bukan apa yang Anda maksudkan. Bukan sedikit pun pengarahan diri sendiri atau intuisi. Ini mengerikan.

Satu hal yang dilakukan komputer adalah, cepat. Betulkah! Orang bodoh dengan lemari arsip bisa melakukan pekerjaan yang sama seperti database. Beberapa orang yang sedang membuat mesin cetak bisa melakukan apa yang Apache lakukan. Serius! Dan mereka melakukan, selama ratusan dan ratusan tahun, sebagai fakta. Mengapa komputer baik untuk APA SAJA adalah kecepatannya.

Jadi bahasa pemrograman yang (dibandingkan dengan bahasa lain) gagal untuk mengeksploitasi yang hilang manfaat HANYA menggunakan komputer.

Bahasa pemrograman bisa tingkat sangat tinggi, "lakukan banyak", masih sangat cepat. OCaml adalah bahasa tingkat yang lebih tinggi dari PHP, tetapi menghasilkan kode hampir secepat C. Javascript sama dinamisnya dengan PHP, tetapi dapat dieksekusi dengan sangat cepat. Jadi, ini terutama masalah dengan implementasi bahasa, bukan desain. Bahasa dinamis lebih sulit diterapkan secara efisien, tetapi bukan tidak mungkin.

Kecepatan dapat diukur dalam hal run-time, waktu pengembangan awal dan waktu pemeliharaan (waktu yang dibutuhkan untuk menyerahkan masalah / bug dan menghasilkan kode baru dan menyebarkannya).

Bahasa scripting pada umumnya memiliki run-time yang lebih lambat tetapi waktu perawatan yang lebih cepat karena Anda sering dapat membuat perubahan dan penyebaran cepat tanpa harus membangun kembali seluruh sistem, dan kadang-kadang bahkan tanpa harus berhenti dan memulai kembali.

Karenanya banyak adalah keseimbangan tergantung pada kecepatan yang Anda butuhkan.

Konteks juga penting. Memuat konfigurasi awal Anda dengan mengambil 0,5 detik, bukan 0,1 detik bukanlah masalah besar, tetapi saat runtime, mengambil 0,5 detik untuk melakukan kueri alih-alih 0,1 detik mungkin menjadi masalah besar jika harus menangani 100 kueri, sehingga mengambil 50 detik alih-alih 10.

Sederhana - pelanggan menyukai perangkat lunak yang cepat. Sebenarnya seluruh tujuan komputer adalah untuk menghitung dengan cepat.

Lambat itu relatif. Jika saya memiliki persyaratan untuk membaca port 10 kali per detik, bahasa yang tidak dapat membuat biner yang dapat melakukannya terlalu lambat. Jika otoh saya sedang menulis aplikasi web di mana urutan permintaan / respons antara server dan browser / klien diukur dalam hitungan detik dan pengguna cenderung menghabiskan beberapa menit di layar sebelum mengklik tombol, bahasa pemrograman yang dapat menangani pemrosesan permintaan dalam 1 detik mungkin cukup cepat (sebagian besar tentu saja jauh lebih cepat).

Tentu saja bahasa pemrograman mungkin menjadi faktor dalam menentukan kecepatan eksekusi, tetapi itu bukan bahasa itu sendiri melainkan kompiler dan / atau runtime yang menyertainya. Ini jelas melihat perkembangan Java, di mana kinerja JVM (bahkan pada lingkungan perangkat keras yang sama) selama bertahun-tahun meningkat secara radikal. Dan tentu saja selalu mungkin untuk menulis kode yang sangat lambat di lingkungan apa pun yang Anda pilih. Karena itu klaim seperti "C ++ sepuluh kali lebih cepat daripada Java" secara otomatis palsu kecuali terkualifikasi dan terkuantifikasi secara tepat kondisi mana yang diuji dan bagaimana. Sama-sama memungkinkan untuk membuat tes di mana Java lebih cepat daripada C ++, semuanya tergantung pada apa yang Anda gunakan sebagai kode uji dan bagaimana Anda menjalankannya.

Karena bahasa pemrograman tidak ada untuk melayani pemrogram, mereka ada untuk membuat program untuk melayani pengguna.

Jika Anda hanya perlu alat pribadi kecil sederhana untuk melakukan sesuatu satu kali, itu bisa sangat lambat seperti yang Anda inginkan. Tetapi begitu Anda mulai menyebar ke pengguna, mereka peduli dengan kecepatan dan penskalaan, terutama jika mereka akan menggunakannya berulang kali. (Misalnya, penginstal bisa lambat; program yang dipasangnya sebaiknya tidak.) Dan itu bukan hanya bahasa; ini adalah keseluruhan program. Jika program Anda lambat, pengguna tidak akan menyukainya. Dan jika Anda memiliki persaingan, pengguna yang tidak menyukai program Anda adalah hal yang sangat buruk. Jadi bahasa yang memberikan kontribusi kepada pengguna yang tidak menyukai program Anda (dengan membuatnya lambat) adalah buruk.

Saya bagian dari tim yang menulis perangkat lunak kontrol untuk media penyiaran. Ada kemungkinan besar stasiun TV atau radio favorit Anda menjalankannya jika Anda berada di AS. Kinerja adalah salah satu hal yang paling sering kita dengar dari klien. Awalnya ditulis untuk operasi stasiun tunggal kecil, tapi sekarang kami menandatangani siaran utama dan jaringan kabel dengan ratusan saluran, dan skala mulai menjadi masalah. Jika kita tidak dapat membuat segalanya berjalan cepat untuk mereka, mereka akan mengambil kontrak jutaan dolar mereka kepada orang-orang yang bisa, dan kita akhirnya kehilangan pekerjaan. Itu sebabnya kami menggunakan bahasa yang dikompilasi dengan cepat dan mengoptimalkan hasilnya dari basis data kami.

Karena lebih cepat lebih baik. Waktu adalah uang. Jika Anda menulis perangkat lunak server dan menggunakan bahasa pemrograman yang lebih lambat, Anda membeli lebih banyak server. Jika Anda menulis perangkat lunak yang menyusut, Anda kehilangan pelanggan karena saingan yang lebih cepat.

Untuk semua jenis perangkat lunak yang tahan lama yang digunakan oleh orang-orang, kami biasanya menginginkannya secepat mungkin. Di tingkat Majelis, waktu ke pasar meningkat terlalu banyak sehingga tidak menguntungkan. Ini semua kompromi. Dari perspektif bisnis, mungkin lebih menguntungkan untuk membiarkan programmer yang buruk men-debug kesalahan memori di C ++, melakukannya selama beberapa bulan lagi, jika itu berarti produk lebih cepat dari pesaing Anda.

Jadi kecepatan sebenarnya penting di banyak perangkat lunak. Bahasa lambat dianggap "buruk" saat ini karena mereka benar-benar terlalu lambat (Python dapat dengan mudah menjadi 50x - 100x lebih lambat, dan itu terlalu banyak)

Bahasa pemrograman ada untuk melayani programmer.

Saya tidak tahu bagaimana Anda sampai pada kesimpulan ini. Saya akan mengatakan: insinyur perangkat lunak menggunakan bahasa pemrograman untuk kebutuhan mereka.

Beberapa bahasa pemrograman lebih lambat daripada yang lain tetapi itu bukan karena ada sesuatu yang salah dengan mereka.

Ini juga pernyataan yang flakey. Tentukan apa yang Anda maksudkan dengan menggunakan kata 'lebih lambat' di sini. Lebih lambat bisa berarti:

1. Program akhir, yang mencapai hal yang sama, menjalankan 'lebih lambat' dalam satu bahasa dibandingkan dengan yang lain.
2. Waktu yang dibutuhkan untuk membuat program akhir mungkin lebih lama (karenanya, beberapa akan menggambarkannya sebagai 'lebih lambat').

Dua masalah yang muncul di pikiran ini juga saling terkait di mana ada semacam pertukaran antara waktu yang dihabiskan untuk pengembangan dan kinerja.

Seperti halnya perangkat lunak apa pun, menjadi lambat bisa menjadi pertanda masalah mendasar / desain yang buruk. Desain memang sedikit zeitgeist memang diakui, tetapi ini tidak mengurangi fakta bahwa prinsip-prinsip desain yang sekarang didasarkan padanya sudah ketinggalan zaman dan dianggap 'buruk'.

Ambil Classic ASP dan ASP.net misalnya.

Seseorang berkomentar bahwa "Pelanggan menyukai perangkat lunak yang memenuhi persyaratan dan sesuai anggaran". Yah, ini benar - tetapi memiliki pengaruh pada perangkat lunak lambat, dan itu, hampir secara definisi berarti bahasa pemrograman lebih lambat (dan kerangka kerja) dan algoritma, dan konfigurasi. Bahasa pemrograman yang lambat mungkin adalah bagian paling penting dari semua hal di atas hanya karena dasar dari mana Anda akan merasa paling sulit untuk berubah. Jika Anda menggunakan Oracle DB dan membutuhkan lebih banyak perf, Anda dapat mengoptimalkan tabel / indeks / dll. Mudah. Jika Anda memiliki algoritma yang buruk dalam kode Anda, Anda dapat menulis kode yang berbeda. Jika kerangka kerja Anda lambat, Anda bisa menggantinya - itu tidak mudah tetapi bisa dilakukan tanpa harus menulis ulang semuanya. Jika bahasa Anda terlalu lambat, Anda harus mulai lagi dari awal.

Lihat Facebook untuk kerumitan yang mereka lakukan untuk membuat PHP bekerja cukup cepat ketika mereka perlu skala.

Bagi kita semua, 'persyaratan kinerja non-fungsional' sering ditulis ke dalam spesifikasi, terutama untuk aplikasi web yang dapat diskalakan. Gagal memenuhi laman 'harus ditampilkan kepada pengguna dalam waktu 2 detik dari permintaan "dan Anda kehilangan kontrak (atau membayar penalti). Jadi, ya, pelanggan menyukai perangkat lunak yang berkinerja untuk reqs - dan req itu akan mengatakan harus cepat (Anda mungkin tidak peduli berapa lama yang dihabiskan pengguna menatap jam pasir, tetapi pelanggan yakin - biaya yang sangat besar).

Sebagai contoh, di sebuah pusat panggilan besar saya diberi tahu bahwa mereka telah menentukan bahwa untuk setiap detik Anda dapat menghemat proses panggilan, 1 pembuat panggilan bisa 'dirampingkan'. Tiba-tiba itu uang sungguhan, dan insentif besar bagi bos untuk mendapatkan perangkat lunak yang lebih cepat, efisien, dan lebih bermanfaat.

Ada banyak waktu yang dihabiskan untuk mengkhawatirkan pemrogram membuat kode secepat mungkin (dan kemudian unit menguji dan refactoring sepanjang waktu, lol). Saya telah menemukan bahwa ini bukan faktor yang banyak orang pikirkan - jika Anda seorang ahli dalam bahasa Anda, Anda dapat mengkodekannya lebih cepat daripada jika Anda tidak berpengalaman. Jadi pakar C ++ dev dapat menulis kode lebih cepat dan lebih akurat daripada pengembang PHP pemula. Jadi saya pikir menjadi seorang ahli lebih penting daripada memilih bahasa yang 'mudah' dan inilah mengapa saya tidak menyukai kultus 'menulis ulang dalam hal-hal baru yang keren' yang sepertinya ada di mana-mana saat ini.

Saya akan menunjukkan bahwa sebagian besar masalah kinerja ada karena programmer melakukan pekerjaan yang buruk bukan karena bahasanya terlalu lambat. Sungguh, ada banyak hal terkait yang perlu dikhawatirkan dalam kinerja daripada bahasa yang Anda pilih. Itu akan menjadi sekitar nomor 1.203.407 dalam daftar saya.

Jadi, apakah kinerja lebih lambat, bahasa pemrograman, sungguh, hal yang buruk?

Semua hal lain dianggap sama, berjalan lebih cepat adalah hal yang baik. Lagi pula, tidak ada yang benar-benar ingin menunggu lebih lama untuk beberapa hasil, dan sekali hasil itu selesai dapat membebaskan sumber daya untuk hal-hal lain.

Tapi tidak semua yang lain sama. Sebagai permulaan, juga penting untuk menghasilkan hasil yang tepat , atau setidaknya cukup tepat. (Jika hasil yang benar-benar salah dibolehkan, Anda dapat menghasilkannya dengan sangat cepat dan hasilnya akan sama sekali tidak bernilai bagi siapa pun.) trade-off yang bagus. Bahasa tingkat yang lebih tinggi memiliki keunggulan dibandingkan bahasa tingkat yang lebih rendah di sini, karena serangkaian model yang lebih kaya biasanya membuatnya lebih mudah untuk mengekspresikan masalah yang rumit tanpa banyak detail yang sangat eksplisit.

Biasanya juga penting untuk mengatur biaya pembuatan perangkat lunak di tempat pertama, menambahkan fitur baru yang diinginkan, dan membuatnya berfungsi ketika sistem yang mendasarinya berubah. Bahasa tingkat yang lebih tinggi biasanya memungkinkan perputaran program lebih cepat, dan ada banyak nilai dalam menjaga biaya pemrograman sesuai anggaran. Memang, menjaga biaya di sana memungkinkan lebih banyak hal yang berbeda untuk dicapai secara keseluruhan, yang umumnya merupakan hal yang baik.

Poin kunci terakhir yang perlu diperhatikan adalah bahwa tidak perlu hanya menggunakan satu bahasa , dan banyak sistem perangkat lunak yang mayoritas komponennya tidak kritis terhadap kinerja. Menggunakan bahasa tingkat rendah untuk menghasilkan komponen berkinerja tinggi untuk bit kritis masuk akal, sementara membiarkan bagian yang kurang penting ke bahasa tingkat tinggi (sehingga untuk meminimalkan biaya produksi mereka) sangat masuk akal. Terlebih lagi, fitur yang membuat bahasa tingkat rendah yang baik (kemampuan untuk mengontrol apa yang dilakukan mesin) bukanlah fitur yang membuat bahasa tingkat tinggi yang baik (kemampuan untuk menyimpulkan rincian dari deskripsi yang jauh lebih kecil): mereka menentang secara diametris, sehingga dapat menyatukan mereka dan menggunakannya untuk kekuatan mereka dan menghindari kelemahan mereka, itu adalah hal yang hebat.

Komponen mana yang harus mendapatkan perawatan berkinerja tinggi? Optimasi? Ukur mereka. Profil mereka. Temukan kebenaran alih-alih menebak. Fokuskan usaha Anda di tempat yang paling baik.