なぜ人々はまだJavaが遅いと言うのですか？[閉まっている]

SOや他の場所で長い間、Javaは遅いという評判があります。ジョークから質疑応答における多くのコメントまで、人々はJavaが90年代のJavaの経験だけに基づいて遅いとまだ信じています。

これが私の問題です。Javaが遅いと人々が信じる（ほとんどの）理由を反証しています。小さなこと以外は、Javaは非常に高速です。

それでは、なぜ人々は今でもJavaが高速であると信じることを拒否しているのでしょうか？C / C ++ではないものが遅いというのは彼らの考え方の一部ですか？人々が時間をかけてチェックしないからでしょうか？それは人々が偏っているからでしょうか？

それはアプリケーションです。お気づきのように、私たちは、Javaコードが、C、C ++、Lisp、VB6、JavaScriptなどのいわゆる「パフォーマンス」言語のパフォーマンスに匹敵するか、パフォーマンスを上回る可能性があることを何度も証明しています。そして、そのような証拠が提示されると、ほとんどの正気でオープンマインドな敵は、恥ずかしげに頭を吊るし、二度とそのような中傷を広めることを約束します。

...しかし、彼らはEclipse、NetBeans、またはGuiffyを起動するか、ブラウザでJavaサポートを有効にするか、お気に入りのフィーチャーフォンでアプリを実行しようとします。そして、彼らはそれが反応するのを待ちます...

...そして待つ...

...そして待つ...



...そして待つ...







...そして待つ...











...そして...




...二度と二度としないと約束したこと？ごめんなさい

この質問は誤った前提で動作します：数えると、Javaはまだ遅いです。重要なのは、大きなデータセットでの計算量の多いアルゴリズムです。確かに、これらは C / C ++コードと同等になるように最適化できますが、モジュール性と汎用性が犠牲になります。効率的なC ++コードは、汎用ライブラリとして使用できるように設計できます。Javaコードはできません。Array.sortすべての基本型に異なる実装を使用し、オブジェクトのバリアントはC ++のジェネリックよりもはるかに遅い、sortこれらのオブジェクトは等値比較を動的にディスパッチする必要があるため、大幅に最適化されたメソッドをご覧ください。

確かに、HotSpotエンジンによって実行されるジャストインタイム最適化により、これらの仮想呼び出しのターゲットを実際に予測し、インライン展開を試みることができます。しかし、これは、C ++のメソッド内でディスパッチされる直接インライン呼び出しよりも遅いですsort。

私の前の同僚は、テンプレート化されたC ++実装とオブジェクト指向のJava実装を使用して、巨大なデータセット（動的図形を使用したqグラムカウント）の問題の比較ベンチマークを行いました。Javaコードは、C ++コードよりも桁違いに遅くなりました。

もちろん、これはリンゴとオレンジを比較しています。しかし、ポイントは、Java実装が（ライブラリに必要なモジュール性の程度を考えるとパフォーマンスの点で）可能な限り最良の実装であり、C ++実装も同様であるということです。

残念ながら、ベンチマークデータは自由に入手できませんが、ランタイム抽象化のオーバーヘッドを比較すると、同様の数値を見つけたものもあります。たとえば、Scott MeyersはCのジェネリック関数のオーバーヘッドについて効果的なSTLに記述していますqsort。

C ++のソートは、事実上、速度に関しては常にCのqsortを困らせます。[…]実行時に、sortは比較関数をインラインで呼び出しますが、qsortはポインターを介して比較関数を呼び出します。[…] 100万倍のベクターでのテストでは、[並べ替え]は最大670％高速になりました…

一部のアプリケーションでは遅いためです。デスクトップアプリケーションは最初から応答する必要があり、起動時のオーバーヘッドは遅いと見なされます。

一方、サーバーを実行する場合は、多少の加熱（JIT分析およびコンパイル）があるかどうかは関係ありません。ブルームーンで1回行うため、ほとんどの場合、完全に遅いとは見なされません。

人々が最初に遭遇したとき、それが遅かったからだと思います。それに基づいて、彼らはそれの印象を形成しました。彼らがそれを使わないなら、その印象は変わりそうにありません、そして、彼らはその印象のためにそれを使いません-それは悪循環です。

私は認めなければなりません、私はJavaが遅いという印象を持っていました、そして、はい、それはそれへの私の以前の露出からでした。私は今、さまざまな言語に移行しており、それ以来、Javaへの露出は非常に限られていました。その結果、私の意見はあまり変わっていません。

製品に関する人々の認識を変えるには世代が必要だから

Javaの高速化とは関係ありません。人々の心では、Javaは「遅い」という言葉に関連付けられたconst識別子です。あなたやオラクルがそれに対してできることはほとんどありません。

オラクルがJavaプログラミングカルチャーを（まだ）破壊的または愚かなことで破壊していないことだけに満足しています。それを使用するために過剰なライセンス費用を請求するようなものです。または、以前Sunが所有していたソフトウェア特許に基づいて人々を訴えます。：：はぁ：：

私はここで反対意見を言うのは嫌いですが、OracleとGoogleがJavaの苦労をいい言葉で解決しない限り、またはGoogleがJavaを購入し、それを「適切な」オープンソースプラットフォームにしなければ、Javaはうまくいきそうですシラミのいる遊び場。IE、誰も20フィートの棒でそれに触れたくないでしょう。

注：明確にするために、私が世代を言うとき、私はコンピューターの用語ではなく、人々の用語で話しています。IE、その認識を保持している人々が老齢で死ぬか、若い世代に取って代わられるまで、認識は真実です。5年ではなく50年という観点で考えてください。

1つの理由は、人々が見るものの代わりに他人が言うことを信頼するからです。

プログラミングを始めたときに私が言われたように、JavaはC ++よりも「遅い」、そしてJavaを使用できる理由は、「便利で簡単」だからです。Javaはパフォーマンスを犠牲にして安全性と利便性をもたらすと非常に一般的に信じられています。後にC＃が発明されたときでも、人々は「ネイティブ」だからJavaよりも高速だと信じています。

しかし、人々が気付かないうちに見る真実は、Eclipse（Javaで構築されたIDE）がクラスで最速のIDEであることです。私はほとんどすべてのメインストリームIDE、MSおよびGNU、BorlandのIDEを使用しました。EclipseはIDEの絶対的な王です。

もう1つの理由は、起動時間が長いことです。

Javaは、システムトレイにとどまり、少しのメモリを消費し、休憩を取るように促すダイアログをポップアップする小さなアプリの開発には適していません。または、テキストファイルを開いて読み、閉じるために使用するメモ帳。常に存在するWebサーバーのように、BIGで使用する必要があります。コンピューティングリソースを最適化して使用し、1時間に何百万ものリクエストに応答します。または、数千のワークスペースファイルを管理するEclipseのようなIDE。Javaアプリが少なくとも数時間実行されるまで高速であるとは知らないでしょう。

@bigown「なぜ人々はまだJavaが遅いと言うのですか？」

彼らは愚かだからです。彼らには仕事の経験がないが、彼らはディクストラの生きた化身であるか、ライナス・トーバルドの再臨であると思うので、ああ、私は知らない。そのような遅滞したことを言う理由は非常に多くありますが、通常は愚かさ、心のない主観的なファンボイズム、感情的な注意喚起が背後にあるようです。

これを分析して、上で言ったことの真実を見てみましょう。

まず、何が遅いのか、どのような状況で、何の条件で、どんな工学/科学/ビジネスの目的で（それが悪いと言うのは、それらの1つではありません。） X、または単に「XはY」です。ここで、Yはある種の否定的な言明であり、上記の質問のいずれにも答えずに、ばかとして却下されるべきです。そのような声明には、エンジニアリングの場所がありません。政治や少年チャットルームでは、エンジニアリングではなく、多分。

第二に、これらの見当違いの愚か者のほとんどは、Javaが遅いと叫びます。なぜなら、彼らの日食は起動するのに永遠に時間がかかるからです。 Eclipseが高速で動作するように（またはJavaアプリケーション用に）jvmを調整する。つまり、彼らはパフォーマンスチューニングについて何の手掛かりも持っていません。これは、Javaだけでなく、ハードウェアであろうとソフトウェアであろうと、重要なシステムにとって現実です。そのため、彼らはそのような心のない発言を行う際の技術的妥当性のために自らを武装解除します。

3番目に、Java開発の大部分が何のためにあるのかを考えてみましょう。監視システムが2番目に来ています。どちらのタイプのシステムも、クラスターで実行することを意図しており、数か月ではなくても数週間中断することなく実行します。REAL Javaアプリの目的が長時間実行することである場合、小さなEclipseまたはおもちゃのアプリのロードに1〜2分かかることは本当に重要ですか？コンテキスト、人、コンテキスト。

最後に、GoogleとEbayのOLTPのバックボーンはJavaで実行されます。私は、Javaが遅くないという矛盾の証拠として（少なくとも、小さなおもちゃの実験、ベンチマーク、および「テヘXは遅い、それは吸う」と言う目的のために行われた検証不可能な事例証拠ではありません。

エンジニアリングがあり、ファンボイズムがあります。これらのようなカテゴリのステートメントが属していると思いますか？

ですから、このトピックを一度だけ永久に閉じることはできますか？

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [表にスクロールすると、JavaはC ++の3.7-12.6倍遅い、Google社員による調査]

PS：そうでない場合は、最初に少なくとも1つのスナッピーなJavaアプリを挙げてください。

TMHO、これはブラウザでVMを起動するために必要な時間のためです。アプリケーションの起動が遅い場合、人々はそれを覚えているだけです。なぜなら、長い開始時間は本当に迷惑だからです。本当に。同僚の一人が、Firefoxは遅すぎるのでFirefoxを使用していないと言った。（？！？）。しかし、はい、はい、Windowsでは、Firefoxが表示されるまでに膨大な時間がかかります。彼によると、このアプリは遅い、彼はそれの一般的な速度について彼の心を作った。

何に比べて遅い？私はそれが速いと聞いたので、普通のRubyからJRuby（JavaベースのRuby）に変更することを考えています。

意見は意見であり、事実は事実です。

Google Code Jamの事実を次に示します。これは、間違いなくプログラマが短期間の厳しいコンピューティング問題を解決することを要求します。つまり、使用する言語のパフォーマンスが重要な役割を果たします。

過去のエディション（2009、2010、2011）では、最終ラウンドに到着したプログラマーの約75％がC ++を使用していましたが、Javaを使用しているのは約15％です。

ソース-> http://www.go-hero.net/jam/

1997年頃、HP Vectra VE（200 MHz）とWindows 95を使用しました。ほとんどのアプリケーションはこれで非常に高速に動作しましたが、Java（IDE、正しく思い出せば）で書かれたいくつかのアプリケーションを試しました。少なくともGUIの部分は非常に遅くなりました。起動に時間がかかり、GUI要素（メニューなど）の反応があまりよくありませんでした。視覚的なフィードバックが遅れていました。また、Java GUIアプリケーションはかなり独特の外観を持っている（持っている）ため、この外観（およびJava）をパフォーマンスの低下に関連付けることを学びました。

遅いという意味に依存します。

まず第一に、javaは最近多くの進歩を遂げ、ほとんどの場合非常に高速です。しかし：

• 何かを行う前にJVMをロードする必要があるため、Javaは起動時に遅くなります。
• 一部のセキュリティ機能は、場合によってはパフォーマンスを低下させる可能性があります。ランダムアクセスによるバウンドチェックは一例です。
• javaで本当に高速なものを作成するには、JVMに対して動作する必要があります（例としてキャッシュラインを利用するため）。
• メタプログラミングの欠如は、各抽象化の実行時にペナルティを意味するため、多くの場合、パフォーマンスが設計のコストになります。
• Javaは、設計上、リアルタイムの制約をほとんど保証できません。これは、一部の人々によっては「遅い」と見なされる可能性があります。

ところで、javaは、場合によってはバニラC / C ++よりも高速です。しかし、それらの言語は、それらを微調整するためのツールを提供します。

Javaは生産性を目的としたプログラミング言語です。現在、ほとんどのアプリケーションでは十分に高速ですが、他の一部のアプリケーションでは十分ではありません。

一般に、Javaの遅さは、ほとんどの場合に見劣りするため、過度に使用される引数です。

単純で標準的なJavaコードは、単純で標準的なC / C ++ / Dコードと同等かそれより高速である傾向があります。シンプルで標準的なコードは、多くのメモリ割り当てを不必要に実行する傾向があり、CPUアーキテクチャに特に合わせたり、低レベルの最適化を大量に行ったりすることはありません。静的コンパイラーができることよりも優れている。

一方、パフォーマンスが本当に必要で、それを手に入れるために手作業で調整する場合は、C / C ++ / Dがさらに多くの機会を提供します。Javaではインラインアセンブラを使用できません。浮動小数点数をビットの配列として扱うために、ダーティタイプパンニングトリックを使用することはできません。特定のユースケースでは、GCよりも高速なカスタムメモリ管理スキームを使用できません。Javaのスタックには、C / C ++ / Dほど割り当てることはできません。Javaでは、高階関数とほぼ同等のものを取得する唯一の方法は、インターフェイスとランタイムバインディングを使用することです。Dおよび（間違っている場合は修正してください）C ++では、関数をテンプレートに渡すことができ、柔軟性を損なうことなくコンパイル時にバインディングを行うことができます。

Javaの「遅さ」のもう1つのポイントは、64ビットランタイムです。

64ビットコンピューターではJavaが非常に遅いと不満を言う人もいます。結局のところ、64ビットJavaランタイムは、起動する前にプログラム全体をコンパイルするサーバーJVMを使用します。

こちらが64ビットVMの起動が遅くなる理由の説明です。

たとえば、Windowsの場合：

C:\> java -version  
java version "1.6.0_21"  
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)  
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)  

Javaのパフォーマンスは非常に主観的ですが、Javaが遅い理由の認識は主に他の人が指摘した理由です：何かのほとんどの人々の認識はそれに対する以前の経験によって色付けされており、Javaは常に十分に最適化された言語ではありませんフード。同様に、バニラエクリプスはVisual StudioのようなIDEと比較すると、正確に動作する高速IDEではなく、応答性の面でも見劣りします。

ただし、Javaの起動時のUIの問題以外は、ほとんどのアプリケーションで十分に高速です。検索すると、他の言語と比較する記事を見つけることができ、提示された結果のほとんどは、主要なデータセットを扱っているときにのみ問題になる範囲に収まります。

バイオインフォマティクスの分野では、十分にサポートされており、すでにインストールベースがあるため、かなり使用されています。Javaの利点の1つは、Cではできないかなり迅速な開発ができることです。 。バイオインフォマティクスに使用される言語（私は個人的にR、Python、およびJavaを定期的に使用しています）を見ると、それらのどれも正確に最速ではなく、バイオインフォマティクスのデータセットが100年代に達することは珍しくありませんギガバイトの情報。結局のところ、人間の時間はさらに価値があり、速度の違いは顕著ですが、データセットのサイズは十分に大きくなる傾向があり、とにかく夜間に実行されます。

JavaでスナッピーなUIを作成する方が簡単だった場合、ほとんどの人は言語を十分にプッシュしていないために速度認識がレーダーから外れてしまうのとまったく同じです。

価値のないコインを投入するために、私はJava webappsが一般に長い起動時間と応答時間を持っていることを発見しました。

私はほとんどのプログラミングにEclipseを使用していますが、Javaは他の何と同じくらい高速であると言わなければなりません。

Javaは、実際の高水準言語では簡単な単純な問題を解決できないため、Javaの動作は単に遅いだけでなく、無限に遅いと言えます。

簡単な例を挙げましょう。森林破壊と呼ばれるリストを2回マッピングする場合に適用される単純な最適化があります。これは、私の言語Felixで記述されたリストのルールです。

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x
;

つまり、リストxをfでマッピングし、次にgで再びマッピングし、2つのリストトラバーサルを必要とし、ガベージ一時リストを作成する代わりに、関数の構成でリストをマッピングします。

これは、Java JVMの低レベルのパフォーマンスよりも大幅に重要な高レベルの最適化です。上記の仕様は単なるきれいな構文ではありません。これは 、ユーザーがFelixコンパイラーに最適化の実行方法を指示することによって書かれた命令です。

この種のことをJavaで行う方法を教えてください。番号？それからJavaは遅いです。非常に遅い。[Haskellはこれを自動的に行うことができると信じています]。

そして「Javaはオブジェクト指向言語であるが、この種の最適化は適用されない」と言う前に..まあそれはまさに私のポイントです。Javaはうんざりしており、オブジェクト指向であることは主な理由の1つです。

JITの最適化は、まともなコンパイラーが行える最適化の種類と競合することさえありません。