Ada banyak studi perbandingan dan tersedia online ketika datang ke kinerja runtime aplikasi yang dibangun menggunakan satu bahasa atau yang lain. Beberapa digerakkan oleh perusahaan, beberapa akademisi, beberapa hanya laporan eksperimen pribadi.

Kami juga mendapatkan bagian studi banding yang layak tentang efek samping dari bahasa pemrograman dan perangkatnya, seperti:

• membangun waktu,
• kemungkinan deteksi bug pasca produksi,
• kekuatan ekspresif,
• dll ...

Namun, saya baru-baru ini semakin tersingkir oleh konsumsi memori program saya lebih dari apa pun. Ini mungkin datang dari fakta bahwa sementara Hukum Moore ada di pihak kita untuk kinerja mentah, kita telah menyadari bahwa kemacetan lainnya lebih penting. Itu, dan saya tidak cenderung memperbarui perangkat keras saya begitu sering, dan saya memiliki beberapa "lama" (baca 2005-2006 3.6GHz Pentium 4 dengan 4GB RAM) yang saat ini sulit ditekan untuk dapat digunakan untuk aplikasi besar tanpa mengharuskan saya untuk melalui masalah besar untuk memeras setiap bit dari mereka (pilihan OS, UI, tweaker layanan dan daemon, pilihan aplikasi untuk digunakan untuk tugas atau yang lain ...). Sejujurnya, kadang-kadang saya bersemangat topatau procexpmenangis melihat memori yang digunakan oleh program yang paling tidak bersalah.

Saya dapat mengatasi hal ini dengan terus mendorong ke arah yang tercantum di atas, dan pada dasarnya mencoba membatasi diri dan program yang saya gunakan (saya rasa saya suka program CLI karena alasan itu, saya kira), tetapi saya juga tidak dapat membantu tetapi berpikir bahwa mungkin kita salah melakukannya.

Alat Modern untuk Kebutuhan Modern

Tentu saja, bahasa tingkat yang lebih tinggi bisa dibilang lebih baik dan membenarkan nilai bobot mati mereka. Beberapa pilihan desain dibuat untuk alasan yang baik (atau seharusnya dimaksudkan dengan baik) pada saat itu, di banyak perkakas. Pustaka bersama, model memori, pra-prosesor, tipe-sistem, dll ... Tetapi beberapa mungkin lebih layak daripada yang lain dengan perangkat keras modern kita, dan saya ingin tahu untuk membaca beberapa studi serius tentang masalah ini.

Jadi, pertanyaan saya adalah, apakah ada liontin pada Game Benchmark dan lainnya yang berfokus pada perbandingan konsumsi memori runtime dasar bahasa?

Dan lebih jauh lagi, apakah ada beberapa penelitian yang mereferensikan silang ini dengan parameter lain (mirip dengan apa yang artikel ini lakukan, misalnya, untuk kriteria lain, juga berdasarkan Game Benchmark )?

^{Saya telah menemukan beberapa informasi parsial, jadi saya akan mulai mengkompilasi temuan saya dalam jawaban saya sendiri. Tolong jangan biarkan itu menghentikan Anda dari menyumbangkan jawaban Anda sendiri (atau mengedit yang ini).}

Sastra yang ada:

• Perbandingan Empiris dari 7 Bahasa Pemrograman - Prechelt (2000) [ PDF ]

  Agak ketinggalan jaman, tetapi mencakup beberapa materi yang saya tertarik dan memberikan tampilan penggunaan memori runtime dan ekspresif. Hasil mungkin sangat berbeda sekarang, tetapi ini merupakan awal yang menarik.

• Kecepatan, Ukuran dan Ketergantungan pada Bahasa Pemrograman - Marceau (2009) [ blog ]

• Kode yang Digunakan, Bentuk Waktu yang Digunakan dari Game Benchmark [ u32 , u32q , u64 , u64q ]

  Meskipun tidak mencakup konsumsi memori runtime, pekerjaan Marceau kurang lebih merupakan jenis referensi atau studi empiris yang saya bersedia untuk menemukan kritera itu, dalam hal konten dan kualitas. Contoh yang bagus tentang apa yang saya cari, hanya untuk metrik yang berbeda. Artikel kedua adalah tindak lanjut yang ditemukan di situs Benchmarks Game dan yang diterbitkan tak lama setelah (dan referensi mana) karya Marceau, dengan layar yang lebih baru dan lebih banyak bahasa, meskipun masih tanpa rincian memori runtime. Setiap grafik pada halaman ini kemudian mengarah ke bahasa-to-bahasa perbandingan yang melakukan memberikan tingkat tinggi informasi memori sekalipun.

Ini tidak menjawab pertanyaan per kata, tetapi mungkin mengubah perspektif sedikit. Saya mengingat transkrip dari obrolan, untuk mengatur nada jawaban-komentar ini yang pasti akan dikenakan banyak suara.

Ada orang, penyedia perangkat keras, penyedia alat, dan pemrogram yang peduli tentang efisiensi. Untuk saat ini, itu akan menjadi kekhawatiran yang berkembang bagi mereka dan kita semua. Kekhawatiran itu berakar pada perangkat seluler, khususnya monster yang melahap baterai bertenaga tinggi dengan layar terbesar dan radio terkuat.

Untuk mengambil satu langkah lagi, bagian dari alasan kita berada dalam situasi seperti sekarang ini, dengan kerangka kerja yang relatif besar, dan sedikit mengabaikan efisiensi umum, di luar peningkatan perangkat keras adalah warisan. Kompatibilitas dengan sistem lama memberi kami kompatibilitas di atas kompatibilitas. Ini bukan kesalahan dari run-times tingkat atas, karena mereka pada dasarnya adalah runtime yang sama bertindak cukup efisien dan performan ketika digunakan dalam lingkungan operasi yang berbeda (misalnya Xbox, windows mobile pre 7/8 / permukaan, java micro framework , dll).

Bandingkan tingkat kompatibilitas yang dimiliki desktop dengan perangkat lunak lawasnya dengan tingkat kompatibilitas yang dimiliki perangkat seluler.

Dengan perangkat seluler, produsen perangkat berupaya memastikan kompatibilitas, tetapi mereka tidak menjadikan kompatibilitas sebagai dasar utama. Ketika pilihannya adalah antara terus memberikan kompatibilitas dan memajukan desain sistem seluler ke depan, sistem seluler bergerak maju.

Untuk desktop, yang sebaliknya tampak benar. Jika perubahan pemecah yang signifikan menyerang pemasar atau pengadopsi awal secara salah, itu mendorong fitur yang diperlukan dan perlu mendesain ulang ke ruang belakang berkali-kali. Pada titik tertentu saya ingat rumor yang menyatakan bahwa kita sebagai pengguna Windows akan menemukan sistem file yang sepenuhnya dan dramatis baru dengan Windows XP, kemudian di Vista, kemudian sama untuk Seven, dan akhirnya lagi di Eight, tetapi tidak, hanya ditingkatkan secara bertahap sejak pertama kali kita melihatnya di Windows2000? File-system baru itu sudah ada sejak lama, dihapus, dan bagaimanapun rumor memutuskan cerita setelah itu, saya tidak bisa mengatakannya. Itu mungkin kasus terbesar yang diketahui, tetapi saya yakin itu bukan satu-satunya kasus besar.

Bahkan dengan tablet dan OS mobile terbaru, Microsoft yang pernah membentuk pasar, sekarang terjalin dalam pertandingan kematian dengan tidak hanya konsumen, tetapi juga bayangan dari departemen desktop. Tablet harus memiliki interoperabilitas yang signifikan dengan rekanan desktop. Tidak, itu tidak bisa bermain sempurna dengan itu, karena perbedaan arsitektur, tetapi juga karena sifat kuno dari dasar-dasar desktop apakah itu membuat pengorbanan yang signifikan.

Sekarang tentu saja, Windows adalah target mudah untuk segala jenis kritik untuk situasi ini, tetapi platform lain jauh dari "bebas dosa". Ada banyak peninggalan yang bersembunyi di ekosistem Linux yang saya yakin menyebabkan kekhawatiran besar untuk perbaikan sistematis.

Ekonomi memainkan peran besar dalam persamaan ini; bagaimana kita membiayai komputasi dan aplikasi kita pada satu, dan bagaimana mereka dibiayai pada yang lain mengikuti pola yang sangat berbeda. Di mana Wintel pernah sangat mempengaruhi keusangan, Apple dan Google telah mengubahnya menjadi jadwal yang ketat. Ini lebih jauh tentunya, daripada yang saya maksudkan, jadi saya akan pergi saat duduk dan membiarkan pembaca mengambilnya dari sana.

Jika dan ketika penyedia besar mengubah model usang dan harga mereka, maka mereka dapat mulai bergerak maju dengan perubahan skala yang lebih besar pada tingkat yang lebih rata. Kerangka kerja tingkat atas yang digerakkan oleh bahasa tingkat tinggi akan menyusut dengan cara, karena mereka akan dapat mencapai tugas tingkat tinggi dengan efisiensi tingkat yang lebih rendah karena kompatibilitas menengah yang tidak efisien dan lapisan tingkat rendah akan dikurangi secara drastis, jika tidak dihilangkan.