多くの比較研究があり、1つの言語または別の言語を使用して構築されたアプリケーションのランタイムパフォーマンスに関しては、オンラインで入手できます。企業によって駆動されるものもあれば、学術的なものもあれば、個人的な実験報告だけのものもあります。

また、次のようなプログラミング言語とそのツールの副作用に関する比較研究のかなりのシェアを得ています。

• ビルド時間、
• ポストプロダクションバグ検出の可能性、
• 表現力、
• 等...

しかし、私は最近、他の何よりもプログラムのメモリ消費量にますます困惑しています。これは、ムーアの法則が生のパフォーマンスに関して私たちの側にある一方で、他のボトルネックがより重要であることに気づくようになったという事実から来ている可能性があります。それと、ハードウェアを頻繁に更新することはあまりありません。「古い」もの（4 GBのRAMを搭載した2005〜2006年の3.6 GHz Pentium 4を読んでいます）があるため、それらからすべてのジュースを搾り出すために大きなトラブルを経験することを私に要求します（OS、UIの選択、サービスとデーモンの微調整、タスクなどに使用するアプリケーションの選択...）。非常に正直に言うと、ときどき起動しtopたりprocexp、最も無害なプログラムが使用しているメモリを見て涙を流したりします。

私は上記の方向に押し続け、基本的に自分自身と使用するプログラムを制限しようとすることでこれに対処できます（その理由から、私はcliプログラムを非常に愛しています）、しかし、私は考えるしかありませんたぶん私たちはそれを間違っているのです。

現代的なニーズのための現代的なツール

もちろん、高水準言語は間違いなくより優れており、それらの重荷の価値を正当化します。いくつかの設計上の選択は、多くのツールチェーンで、当時は十分な（またはおそらく意図された）理由で行われました。共有ライブラリ、メモリモデル、プリプロセッサ、タイプシステムなど...しかし、最新のハードウェアでは、他のものよりも実行可能性が高いものもあるので、この問題に関するいくつかの深刻な研究に興味があります。

ですから、私の質問は、ベンチマークゲームなどの言語の基本的なランタイムメモリ消費量の比較に焦点を当てたペンダントがあるのでしょうか。

さらに、これを他のパラメーターと相互参照するいくつかの研究がありますか（たとえば、この記事が他の基準についてもベンチマークゲームに基づいて行ったのと同様）。

^{いくつかの部分的な情報を見つけたので、私は自分の答えで自分の発見をまとめ始めます。自分の回答を投稿する（またはこれを編集する）ことを止めないでください。}

既存の文献：

• 7つのプログラミング言語の実証的比較 -Prechelt（2000）[ PDF ]

  少し古いですが、私が興味を持っている資料の一部をカバーしており、実行時のメモリの使用と表現力についての見解を提供します。結果は今は大きく異なるかもしれませんが、興味深いスタートです。

• プログラミング言語の速度、サイズ、および信頼性 -Marceau（2009）[ ブログ ]

• コードに使用され、時間がシェイプを使用しますから、ベンチマークゲーム [ U32、u32q、U64、u64q ]

  ランタイムメモリの消費については説明していませんが、Marceauの研究は、コンテンツと品質の点で、多かれ少なかれ、その基準で見つけたいと思う種類の参照または経験的研究です。さまざまな指標について、私が求めていることの良い例です。2番目の記事は、Benchmarks Gameサイトで見つかったフォローアップであり、Marceauの作品の直後（および参照）に公開されましたが、ランタイムメモリの詳細はありませんが、最近の画面と言語が追加されています。これらのページの各グラフは、言語間の比較につながりますが、高レベルのメモリ情報を提供します。

これは言うまでもない質問への回答ではありませんが、おそらく見方を少し変えます。私はチャットからの筆記録を念頭に置いて、多くの反対票の対象となるこの回答コメントのトーンを設定します。

効率を気にする人々、ハードウェアプロバイダー、ツールプロバイダー、プログラマーがいます。当分の間、それは彼らと私たち全員にとってますます大きな関心事になるでしょう。これらの懸念は、モバイルデバイス、特に最大の画面と最強のラジオを備えた高出力のバッテリーを食い荒らすモンスターに根ざしています。

もう一歩戻ると、ハードウェアの改善を超えて、比較的大規模なフレームワークと一般的な効率をわずかに無視している現在の状況にいる理由の1つはレガシーです。レガシーシステムとの互換性により、互換性に加えて互換性も確保されます。異なるオペレーティング環境（Xbox、windows mobile pre 7/8 / surface、javaマイクロフレームワークなど）で使用した場合、それらは本質的に同じランタイムであり、非常に効率的でパフォーマンスが高いため、トップレベルのランタイムのせいではありません。 、など）。

デスクトップが持つレガシーソフトウェアとの互換性の程度と、モバイルデバイスが持つ互換性の程度を比較します。

モバイルデバイスを使用する場合、デバイスプロデューサーは互換性を確保するために多少の努力を払っていますが、互換性を主要な基盤にしていません。互換性を提供し続けることと、モバイルシステムの設計を前進させることのどちらかを選択する場合、モバイルシステムは前進します。

デスクトップの場合、その逆が当てはまるようです。重大な重大な変更がマーケターやアーリーアダプターに誤って打たれた場合、それは必要な機能を押し込み、何回も再設計する必要がありました。ある時点で、WindowsユーザーがWindows XPで完全に劇的に新しいファイルシステムを見つけ、その後Vistaで、後で7と同じようになり、最後に8で再び同じようになり、ついに徐々に改善されたという噂を覚えています。私たちは最初にそれをWindows2000で見ましたか？新しいファイルシステムは長い間存続し、廃棄されましたが、噂はその後話を決めるとは言えません。それはおそらく最大の既知のケースですが、私はそれが唯一の大きなケースではないことを確信しています。

最新のタブレットやモバイルOSでさえ、かつて市場を形作ったMicrosoftは、今や消費者だけでなくデスクトップ部門からの自身の影とのデスマッチに絡み合っています。タブレットは、対応するデスクトップと大幅に相互運用できる必要がありました。いいえ、アーキテクチャの違いのためだけでなく、完全に再生できませんでしたが、デスクトップの基盤の古風な性質のために、かなりの犠牲を払っていました。

確かに、Windowsはこのような状況に対するあらゆる種類の批判の簡単な標的ですが、他のプラットフォームは「罪のない」ものとはほど遠いものです。Linuxエコシステムには多くの遺物が潜んでおり、それらは系統的な改善に大きな驚きをもたらします。

経済学はこの方程式に大きな役割を果たします。コンピューティングとアプリケーションの資金調達方法と、それらの資金調達方法は、驚くほど異なるパターンに従います。Wintelがかつて陳腐化に強く影響していたところ、AppleとGoogleはそれをほぼ厳密なスケジュールに変えました。これは、私が意図したよりもコースから外れているので、そのままにして、読者にそこから取らせます。

大手プロバイダーが陳腐化モデルと価格モデルを変更すると、大規模な変更をより均一なレートで進めることができます。非効率的な中間互換性と低レベルのレイヤーは、排除されない場合でも、大幅に削減されます。