パフォーマンス：私の名前は何ですか？ -大規模プロジェクトでの最適化に関するAlexey Shipilev

パフォーマンスの最適化は長い間開発者を悩ませてきており、興味深いソリューションと優れた実績の一種の「黄金の鍵」のように見えます。 前回のJPoint 2017で、大規模プロジェクトの最適化の主要なマイルストーン（一般原則からトラップや矛盾まで）の大規模な概要ツアーが、パフォーマンスの専門家であるAlexei Shipilevによって行われました。







カットの下-彼のレポートのデコード。



そして、ここでプレゼンテーション自体を見つけることができます： jpoint-April2017-perf-keynote.pdf



スピーカーについて

Alexey Shipilev-10年以上にわたるJavaパフォーマンスの問題。 現在はRed Hatで働いており、そこでOpenJDKを開発し、そのパフォーマンスに取り組んでいます。 JMH、JOL、JCStressなど、OpenJDKのいくつかのサブプロジェクトを開発およびサポートします。 Red Hatに入社する前、彼はIntelでApache Harmonyに取り組み、その後Oracleに買収されたSun Microsystemsに移りました。 生産性とマルチスレッドの問題に取り組んでいる専門家グループとコミュニティに積極的に関与しています。



私はRed Hatで働いています。 以前、私がOracleで働いていたとき、「セーフハーバー」スライドを挿入しました。 製品にソリューションを実装しようとしている場合、そこに何が真実で何がそうでないかを教えてくれる専門家を雇うことは素晴らしいことです。

大：開発の成功の基準は何ですか

製品を開発しているとします。 あなたにとって成功する製品とは何ですか？ 私たちはすべて商用プログラマーです。 コーディングしたものの給与を支払うことで、自分を欺くことができます。 しかし、実際には、製品を提供するサービスまたは製品全体を販売するために、給与が支払われます。







しかし、製品の成功のための純粋に開発上の基準は何ですか（ビジネス目標を除く）？

• プログラマーとコミュニケーションをとるとき、彼らは通常、良い（成功した）製品は正しい実装を持つ製品だと言います 。
  
  
• その後、警備員が来て言います。「もちろん、あなたはそこでだまされましたが、そこに穴がないことを確認するのは良いことです。」 それ以外の場合は販売しますが、その後彼らは私たちを法廷に引きずり込みます。」 ただし、これもポイントではありません。
  
  
• プロジェクトの成功の主な基準は、ユーザーの希望で起こったことの順守です 。 もちろん、優れたマーケティング部門があれば、彼は結果が彼が望んでいるものであるとクライアントに説明できます。 しかし、ほとんどの場合、クライアントにこれを理解してもらいたいです。 多くのプログラマーは、そうであるように、皮質下で、これを意味しますが、それを直接口頭で話す人はほとんどいません。
  
  
• 4位のどこかには開発のスピードと容易さがあります 。 これは利便性であり、プログラマの狂気ではありません。 雇用中にHRと話をすると、あらゆる種類のパン、マッサージなどが約束されますが、実際には、あなたはまだ働いており、辞めない限り、ビジネスはそこでの生活を気にしません。 また、コードは条件付きで適切に記述されており、ウィンドウから飛び出したり、別の会社で仕事をしたいというわけではありません。
  
  
• 通常、 パフォーマンスは優先度リストでさらに低くなります。 多くの場合、成功の基準にさえありません。 製品は少なくとも何らかの形で動いています、そして神に感謝します。
  
  

そのため、HabréでのJavaのパフォーマンスに関する投稿を読んで、そこに同様のコメントが表示されていることに驚いています。







専門家は次のように述べています。 彼女は元気に働いています。 私たちは満足しています。すべてが順調です。」 しかし、コメンテーターが来て答えます。「4人の専門家の誰もがJavaを高速と評価していないことは非常に重要です。 むしろ、十分かつ満足のいくものです。」



悪いと言います ビジネスの観点から、テクノロジーがビジネス基準を満たしている場合は、神に感謝します！ 私はすべてをなめらかに、スムーズに、完璧に舐めるべきだという理想主義的な考えは持っていません。 これは起こりません-通常、製品にはエラーが含まれています。

正しいプログラムと速いプログラム

人々は長い間、プログラムの正しさについて二重に考えることを学びました。 （聴衆に尋ねる）誰が彼のプログラムにバグがあると正直に言うことができますか？ （ホールには多くの手があります）大多数。 それでも、彼らは自分たちのプログラムが多かれ少なかれ正しいと信じています。 正しいプログラムの概念は、高速プログラムの概念と対称的です。







「正しいプログラム」とは、ユーザーのエラーが表示されないプログラムです。 つまり、実際にはエラーがありますが、ユーザーに製品の購入を拒否させることはありません。 「高速プログラム」には対称的な状況があります。パフォーマンスの問題がないということではなく、ユーザーが何かを実行しようとするたびにこれらの問題が発生するわけではありません。



「成功基準に投資しました。」 成功には機能とパフォーマンスの両方の基準があります。プログラムが100ミリ秒を担当するのが適切です。 答えは？ さあ、先に進みましょう。



「正しいプログラムのバグの数は通常わかっています。」 これは、プロジェクトの成人期の指標の1つに過ぎません。プログラムにバグがないということは、バグトラッカーにバグを登録することを誰も気にしないということです（ユーザーがいないためです！）。 パフォーマンスの問題についても同じ話です。 パフォーマンスの問題は既知であり、これは「高速」プログラムであると言います。 （航空見積もりを作成）









正しいプログラムと高速プログラムの両方で、これらのパフォーマンスと機能のバグを回避する方法が知られています。 FAQには次のようなものがあります。「そうすると、傷つきます。 まあ、 それをしないでください 。」

プロジェクトの開発段階-それらへの曲線。 W

私がパフォーマンス作業に参加したほとんどすべてのプロジェクトは、いくつかの標準的な開発フェーズを経ています。 私はかつて、これらのフェーズが次のようになることを定式化しました。







これはパラメトリックグラフです。時間はポイント「A」からポイント「B」、「C」、「D」、「E」に流れます。 縦座標軸に沿ってパフォーマンスがあり、横座標軸に沿って抽象的なコードの複雑さがあります。



通常、すべては、ゆっくりとしかしゆっくりと動作するプロトタイプをサイクリングする人々から始まります。 私たちは自転車が自重で崩れないように自転車で走るので、それは非常に複雑です。



最適化が開始された後、ゆっくりと、さまざまな部分の書き換えが開始されます。 このグリーンゾーンにいる開発者は、通常、プロファイラーを使用して、明らかにひどく書かれたコードを書き換えます。 これにより、同時にコードの複雑さが軽減され（不良部分を排除するため）、パフォーマンスが向上します。



ポイント「B」で、プロジェクトは「主観的」な「美」のピークに達します。これは、パフォーマンスが良好で、製品のすべてが良好であるように見えるときです。



さらに、開発者がより高いパフォーマンスが必要な場合は、より正確なプロファイラーを取得し、適切なワークロードを作成し、ナットを慎重に締めると、イエローゾーンに移動します。 このプロセスで、彼らは生産性のためでなければ彼らがしないであろうことをそこで行います。



さらに必要な場合は、開発者が生産性の最後のパーセントを得るために製品をひねり始めると、プロジェクトはレッドゾーンになります。 このゾーンで何をするかは明確ではありません。 少なくともこの会議用のレシピがあります-JPoint / JokerConf / JBreakに行き、製品開発者を拷問して、下層の曲率を繰り返すコードを書く方法を教えてください。 原則として、赤いゾーンには、下層で発生する問題を繰り返すものがあるからです。



レポートの残りの部分では、これらの領域で通常何が起こっているかを詳しく説明します。

グリーンゾーン

グリーンゾーンの動機付けカードは、ブルートフォースによるコードのバリとの戦いです。







ブルートフォースとは、正確なツールが必要ないことを意味します。 グリーンゾーンにはいくつかの精神的なtrapがあります。



私のお気に入りは、「正常にプロファイルするか、何もしない」です。







「Shipilevのレポートを聞いてください。通常のプロファイルを作成する必要があるかどうかを教えてくれます。」 私はそれを言ったことがない。 あなたがグリーンゾーンにいるとき、診断の精度はほとんど影響しません。 そして、一般的に言えば、「マイクロサービスモノリス」のどの部分を記述したかを理解するには、プロファイリングが必要です。最初に書き換える必要があります。

プロファイリングと診断

ブレンダン・グレッグなどのさまざまなクールなパフォーマンスの男のブログを見ると、彼はそのような恐ろしい図を表示し、そのようなツールを使用して前後に見ることができると言います：







多くの人は、これらのチャートを見ると、「パフォーマンスは非常に難しいので、それはしません」と言っています。 実際、ブレンダンの考えはそれについてではありませんが それは、アプリケーションで何が起こっているかを迅速に評価するためのかなり簡単な方法があるという事実です。 少なくとも大規模なセルの理解があれば、はるかに良くなります。



したがって、グリーンゾーンでの診断は、非常に単純なアイデアに基づいています。アプリケーションを見るのを恐れないでください。 スタックのリソースに不足しているものを大規模に理解することでさえ、注意を払う価値のあるものとそうでないものについての考えをすでに与えてくれます。 完全なシステムプロファイリングを行ったとしても、ボトルネックのある場所はすでに明確になっています。

プロファイリング

グリーンゾーンでの目標は、どこで時間を過ごすかを大まかに理解することです。







スティックやドングリから収集できる素朴なプロファイラでさえ、グリーンゾーンで意識的なアクションを実行するのに十分な情報を提供します。



悪の管理者がプロファイラーのインストールを許可していないプロダクションがある場合は、sshを介してjstackを実行し、「trueのとき」を実行できます。 jstackを実行します。 睡眠1; 完了しました。」 これらのjstackを1,000個収集し、集約します。 これは「ニーハイ」プロファイラーになり、製品の何が悪いのかを十分に理解できます。



ストップウォッチを手に入れて、製品のこの部分で時間の80％を、製品のこの部分で20％を費やしていることに感謝していても、何が起こるかについてコーヒーかすを推測するよりも良いでしょう2005年にVasyaが作成したランダムに作成されたクラスで何かを修正します。

パフォーマンス測定

プロファイリングに関連する次の精神的なtrapは、パフォーマンスを通常に測定する必要があるか、まったく測定する必要がないことを示しています。







私はいつもそれについて聞いています。 しかし、改善のグリーンゾーンでは、通常「プラスまたはマイナス1キロメートル」が目で見られます。 通常、彼らはこれを「あなたは悪いベンチマークを持っている、何も表示されていない、それは不十分に書かれており、パフォーマンスを正しく測定する必要がある」という文脈で言いますが、同時に、ほとんどすべてのワークロードで見られるレーキがあります。

道徳

モラルは非常にシンプルです。グリーンゾーンでは、些細なストレステストでも大きな欠陥が表示されます。







Twitterに公開リンクを張ったり、ベータテストに来てアプリケーションを台無しにしたりする人々を集める代わりに、JMeterでストレステストを書くのに何週間も費やしているケースを見てきました。プロファイラーと一緒に座って、落ちた場所を確認します）。 通常のApache Benchでさえ、十分に十分な欠陥を示しています。



開発中の主要な欠陥に関するこれらのパフォーマンスデータをより早く取得するほど、迅速に修正できます。 これは、特にパフォーマンス作業を計画するのに役立ちます。

サプライズの例

私は最近、JDK 9 Early Accessを使用して、次のように考えました。それを使用してプロジェクトをビルドしようとする必要があります。







構築中です。コンパイル時間は2分から8分に増えています。突然。 この状況では、これが本当に回帰であることを証明するために、このためのきちんとしたベンチマークを書く必要がありますか？







もちろん違います。 ビルドに特定のバグがありますが、再現可能です。 プロファイラーでは、javacの有名な場所につながる呼び出しスタックがあることがわかります。 このjavacでは、ソースコードが見つかり、そこに2次ループが見つかります。



次のような場合に、これが問題であることを証明する必要がありますか？a）ワークロードが悪い。 b）そこに示されるプロファイルはいつありますか？c）二次サイクルが悪いという理論的考察 いいえ、それで十分です。

最適化

別の精神的なtrap：「時期尚早な最適化はすべての悪の根源です。」







もちろん、Knutはまだ健在です。 しかし、誰かがこのフレーズを思い出すたびに彼がどの程度しゃっくりするかはわかりません。なぜなら、このフレーズは通常、誤って覚えられているからです。 Knut氏によると、99.7％のケースでは、時期尚早の最適化がすべての悪の根源であり、人々は最適化が必要な場所を理解していないからです。 あなたがグリーンゾーンにいるとき、あなたは気にしません。 とにかく美しいコードを書き直します。 最初に書き換える内容を決定するには、プロファイリングが必要です。



どんな通話がありますか？



原則として、パフォーマンスの改善は、主に「悪い」コードを「良い」に書き換えることです。 しかし、「悪い」と「良い」は、ある程度主観的な味です。 少数のプログラマーに尋ねてください。あなたはこのように必要なものをとても美しいと言うでしょう。 もう1人は「ここに何を書いたの！」と言うでしょう。 もちろん、これはすべて味わうことができますが、「Effective Java」という本を書いたあなたやJoshua Blochに悩まされているものを含む、トリックに悩まされることもあります。







たとえば、効果的なデータ構造。 グローバルs / LinkedList / ArrayList / gがためらうことなくパフォーマンスを改善したプロジェクトを知っています。 LinkedListの方が高速な場合もありますが、これらの場合は非常に特殊であり、通常は肉眼で見ることができます。



HashMapを使用できる場所でArrayListを線形検索していることに突然気付く場合があります。 1組のkeySetとgetを繰り返して、entrySetに変更するか、bubbleSortを循環させて、突然100万個の要素のコレクションがそこに来て、そこに多くの時間を費やしている、などです。

グリーンゾーンの小計

プロファイリングは、日々の開発に必要な部分です。



私の観察によると、パフォーマンスの問題の95％は最初のプロファイリング訪問で解決されています。 プロジェクトの複雑さに関係なく、経験のある人々がどのようにプロジェクトを開発しても、プロジェクトの最初のプロフィールを人々に見せると、彼らは感情の範囲、特に「私たちは馬鹿だ」と感じます。 これらの問題の90％以上が自明に解決可能であり、理論的には、コミット前にキャッチされるべきだったからです。



テクニカルエキスパート、アーキテクト、テクニカルディレクター、または他の主要な技術的地位を占めており、生産性が必要な場合は、プロジェクトにプロファイラーを起動するための明確な指示があることを確認してください。 ライナーが1つ、ボタンが1つ、またはAPMを備えたWebアプリケーションがある場合は、非常に便利です。 開発者は常にこれを迅速に行う方法を持っている必要があります。



私の経験では、開発者の手を取り、彼がいくら年をとっても、彼らと一緒に座って製品をプロファイリングすれば、パフォーマンス作業に対する彼の恐怖を確実に止めることができます。 多くの人々は、パフォーマンスが難しいほど、コンポーネント間にさまざまな相互接続があるなど、頭の中にそのようなブロックを持っています。 そして、彼らはまったくプロファイリングしません。それは難しいからです-つまり、これまでのところ、それは必要ではありません。 しかし、一度座って一緒にやると、彼らはこのブロックを削除し、自分でプロファイルを開始します。 そして、誰かが来る前に解決できるエラーの90％は、プロフィールを見せて恥をかかせ、事前に修正します。



さらに、「開発者の手を取ります」-これは、会議に1000人収容することを意味しているわけではありません。スピーカーが出てきて、スマートな外観でプロファイラーに何かを運び始めます。 これは機能しません。 動作が異なります。プロジェクトの特定の開発者と一緒に座って、カップルでそれを行います。

イエローゾーン

イエローゾーンは、パフォーマンスと引き換えにコードが複雑になることを意味します。これは、パフォーマンスを上げたくない場合に実行しないことを行う場合です。







精神的なtrapもあります。

プロファイリングと診断

最初のメンタルトラップ：「プロファイラーを使用して、最適化を開始する場所と方法を確認します。」







黄色のゾーンでは、エラーの価格が上昇していることがわかります。生産性は得られますが、保守性、開発者の睡眠など、代わりに何かを失うことになります。 したがって、高度な診断を必要とする適切な変更を行う必要があり、プロファイリングは診断の一部にすぎません。 ベンチマークなどもあります。



通常、人々は黄色のゾーンを掘り下げて、何を最適化すべきかを考え始めると、プロファイラーを開いてこれを見る：







そして、ここで何を最適化しますか？ java.nioで書き換えるか、最もホットなメソッドはjava.lang.Object.waitであると言います。つまり、オーバークロックする必要があります。 または、Unsafe.parkがあるため、オーバークロックする必要があります...またはSocketInputStream.socketRead0、またはsocketAccept-ネットワークが表示されるため、すべてを緊急にNettyに書き換える必要があることを意味します。 確かに、このゴミはすべてJMXからのものですが、3か月の開発の後、これについては後で確認します。 または、Object.hashCodeがあります-悪いHotSpotがそれを最適化しなかったとしましょう。しかし、「すべてが速くて良いものになると約束し、製品は責任を負いません」。



黄色のゾーンの操作方法は簡単です。最適化、これを行う理由を説明する必要があります。 たぶんあなた自身のためか、あなたのプロジェクトマネージャーのためでしょう。



持っていることが望ましい：

• 成長の数値推定
  
  
• すべてのリソースを使用する前にそれらを用意することをお勧めします 。 そして、3か月の開発が終わったときではなく、「ああ、あなたは知っています、このタスクには3か月かかりました、クールです。」
  
  
• これが最も安価な方法であり、この方法が全体的なパフォーマンスを改善する方法であることを理解する必要があります。
  
  

アムダールの法則

生産性を評価するためにタスクを依頼すると、経験の浅い人がひどくごちそうになります。なぜなら、頭の中に非線形の依存関係を置くのは非常に難しいからです。 これらの非線形依存関係の1つはアムダールの法則であり、通常は次のようになります。



アプリケーションがあるとします。 AとBの2つの独立した部分があります。たとえば、A部分は70％の時間で2倍加速し、B部分は30％の時間で6倍加速します。 分散できるのはそのうちの1つだけです。これには十分なリソースしかありません。 どのシステムをオーバークロックしますか？ 単にグラフィカルに削減しても、次のことがわかります。







パートAは、合計時間の70％で機能します。 パートAを2倍だけ加速するという事実にもかかわらず、パートAを最適化することをお勧めします。 全体的なパフォーマンスへの影響が大きくなります。



もし私がフリーランスのプログラマーなら、おそらくパートBを6回オーバークロックするでしょう。 私の週報では、この数字はもっと良く見えるだろう：「Vasyaは2倍になり、私は2倍になったので、給料を3倍増やす必要がある」。



アムダールの法則は次のように推測されます。







スピードアップSがある場合、定義により、合計時間A + Bを新しい時間で割った値になります。 パートBは同じままであるため、「プラスB」があり、パートAはS _A回減少しました。 この付録でパート_Aとパート_Bの相対時間を示すパート_Aとパート_Bの 2つの表記法を導入すると、次の式になります。









この比率には楽しい特性があります。 たとえば、S _Aを無限に向ける場合、制限S：









これは明らかなことではなく、理解するために自分の肌で何度も感じる必要があります。 彼らはここでそのようなグラフを通してあなたを示します：









...そして言う：加速する部分が80％を占有するアプリケーションがある場合、そのポイントまで加速しますが、スピードアップが5倍を超える場合、それは得られません。



これは、データベースベンダーがあなたに来て、次のように言っていることを意味します。データベースがワークロードの50％を占有していることがわかります。 1行のコードを変更せずに現在のソリューションを当社のものに変更すると、パフォーマンスが10倍になることを保証します。 彼に何と言わなければならないのですか？ （観客から）ブルたわごと！



さらに進んでください：アムダルの法則の一般化があります。 これらの用語を少しひっくり返して、2つの新しい表記法を導入すると、pは高速化され、AはAの特定の部分を分散させた時間であり、alphaは他のすべての部分の量です。この法則は次の形式で記述できます。







問題は、これらのメンバーに何らかの物理的意味があるということです。 通常、最初のメンバーは並行性と呼ばれます 。 今のところ、2番目の用語-競合-を無視すると、表現は次のことを意味します：パートAを何回加速したか、一般的なスピードアップをどれだけ得たか。 競合は、アムダルの法則でこれと同じ漸近線を提供する他のすべての生産性への影響を説明しています。 ところで、この関数のグラフを描くと、アムダルの法則と同じ曲線が得られます：











ただし、原則として、ほとんどの場合、この形式のアムダールの法律は適用されません。 コヒーレンスと呼ばれる、コンポーネント間の相互作用を記述する別のメンバーがそこに追加されると、より複雑な法則が適用されます。







アルファとベータが負でない場合、飽和漸近線がないことがわかります。 何らかの効率のピークがあり、その後、生産性が低下し始めます。 パフォーマンスに関わる多くの人々は、この法則をユニバーサルスケーラビリティ法（USL）として定式化するまで、自分の肌で感じていました。







ここでは、「普遍的」および「法則」の概念が自然科学的な意味で使用されています。つまり、理論的に正当化されていますが、分析的には導き出されていません。 これは、経験的証拠にまで及ぶ法律として推定されます。



アルファとベータがゼロに等しいシステムはありません。システムにリソースを追加したり、何かを最適化したりする場合が多く、悪化するためです。 たとえば、あるボトルネックを取り除いたが、別の重いボトルネックにぶつかりました。

パフォーマンス測定

パフォーマンスを測定するメンタルトラップには、「すべてが複雑であり、すべてがパフォーマンスに与える影響がわからないため、何かを見つけてベンチマークが示すことを確認するだけです」とあります。







実際、パフォーマンステストは非常に高価であり、特にすべてをテストすることはできません。 パフォーマンステストは、機能テスト（ユニットテストなど）がパックで実行される場合でも、100ミリ秒以下で合格するという点で機能テストと異なります。 パフォーマンステストでは、物事はそれほどスムーズではありません。 1分以上からテストに合格し、数時間かかる場合があります。 これは、1つの変更を数百時間のマシンでテストできることを意味します。 1日に大量のコミットを行う場合、テストシステムを介して何らかの方法でアクセスを提供するには、非常に多くの機器が必要です。



パフォーマンステストには隔離が必要です。



原則として、パフォーマンステストは非バイナリメトリックを提供します。 通常、機能テストは「PASS」または「FAIL」、つまりバイナリメトリックを示し、パフォーマンステストは...「67」を示します。 さらに悪いことには、彼らは67ではなく、67プラスマイナス5と言います。 これは、とりわけ、テストエラーはデータを解析した後にのみ検出されることを意味します。すべてがどこでも非常に美しいことを理解しているときですが、ここでは、暗い隅に、実験が焦げていることを示すデータがあります。 , .



, - , - — - , . , , , , , .



— . , , , .

: .







, «», , , end-to-end , , -. .



— , , .



, , — .



: — , — . () , . , — . , — real world . , , «real world». , . , , . «real-world», , , , .



— . , , . , , , , , . , , , . , , , , white paper- , , .. .

bull shit , , .









— , , .., «» , , . , . .









, , bottleneck, . , , . .



. .









— , . 0, speedup . ( , , 2 ), , , , .









, , .



:







speedup , — speedup . , - , , , , .



, — . .







. - 50 , , 50 , . , , , , , , , — . , , , .



:

:

• , ;
  
  
• , ;
  
  
• .
  
  

すなわち — .



:

• , , , : , , - ;
  
  
• ;
  
  
• , .
  
  

, , , ( ), . , .



, . , « - » , . , , , , , , — , , . , .

最適化

, , . :







« , — 100 , a 110. , …» - JPoint. , , , , - . , branch prediction - (, , -, ).



, , , . , . , ( , , ):

1. , , — N^3, N log N. , , , , , ;
   
   
2. , , , , , , . , PR , ;
   
   
3. . , , , -;
   
   
4. , . , , .
   
   

, , , - , , . , , , ..

JVM

: , , , JVM, ? : , ( , JVM).



, , . Google : «JVM tuning options». :









, - , « JVM».



, . , , , . , , , .

, , parallelStream(), Eexecutor.submit, new Thread, . ? , , , - .



: , , . — , dispatching . staging, , . , , - , - -Hadoop, MapReduce; , . , , 10 000 , .. — , .

別の例。 : « , - Integer Java — , int ».



, «int- — » , , , . , , : , , ( , - , , , ), JDK - Valhalla.

Modus operandi: — , , , . .



50% , . : , , « » .



, 80% ( 83% , , ).



. , , , , , , . . , , , , , . , .

: , . — , , . , .









, , - , , : « »!



— .







例：

• , , , , - . : reflection ;
  
  
• または、ライブラリのコースを読んで、パブリックメソッドを特別な順序（このAPI鍼治療と呼びます）でプルすると、このオブジェクトをより受け入れやすい状態に変換することがわかります。
  
  
• または、プライベートAPIをすべてダウンロードしてダウンロードします。
  
  
• または、実行している特定のハードウェアの機能、つまりターゲットとする特定のJDKの機能を活用し始めます。 低レベルの最適化を行います。
  
  

プロファイリングと診断

通常、誰もが偶然このゾーンに行き着きます。 可能なすべてのオプションが選択されると、彼らは自分自身に言います：「それでは、次に何をすべきかを考えます。」 そして、あなたが長い間プロファイルを見ると、あなたは解決策を見ることができるようです。 彼らは決定が難しいことを理解しています。つまり、見るのに長い時間がかかることを意味します。







実際、レッドゾーンをハッキングする能力は、可動部分の相互作用を理解することから生まれます。 そして、この場所にはパフォーマンスアーティストが登場します。これらは特に他のすべてに専念しているわけではありませんが、一度にすべてのレイヤーを掘り下げることができます。 彼らは歩行百科事典であり、頭の中にはそのような状況で働くハックのセットがあります。 彼らは適用の限界を知っています。 最も重要なのは、これらの人々は、見慣れないがらくたを見てもwhen然としないが、それを勉強し始める人々です。



何も明確でないプロファイルが表示された場合、「では、このプロファイルを削除して、新しいデータをもたらす実験をしましょう」と言います。 データを収集する体系的な帰納的方法がここで機能します。 彼らのために勉強するということは、コードをダウンロードしてStackOverflowに投稿し、「このようなパフォーマンスの問題はありますか？」と尋ねるのではなく、John Skeetなどの人々が来るのを待ちます。彼らはそこでどのように、何をする必要があるかを教えてくれます。 勉強とは、ドキュメントを読んだり、記事内の参考文献を探したり、実験をしたり、同僚から知識を引き出したり、何らかの方法で整理したりすることです。 多くの人々がこのために会議に来ます。

会議のコツ

別のメンタルトラップがあります：「長い間会議に行った場合、いつかいくつかの会議で彼らは私たちのプロジェクトを5倍改善するトリックを伝え、その後チケットに費やした予算全体を取り戻します。」







実際、特定のケースでは、1000回の保存のうち1つの低レベルのトリックです。 海辺で天気を待つよりも自分で見つける方が簡単です。 プログラミングパーティーで最も面白いのは、パフォーマンスに関する議論のほとんどが低レベルのハッキングに関するものだということです。







原則として、これらすべてのことは、プロジェクトのプログラマーが単純なアルゴリズム変換を使用して、パフォーマンスを何倍も改善できる状況で発生します。 しかし、彼らは会議でスマートHotSpotが何らかの形でコンパイルされると言われたので、HotSpotでうまくコンパイルされるようにプロジェクトを修正する必要があるので、彼らは主なものを見逃しています-彼らは実際に自分で見つけることができる変更を持っています高速です）、パフォーマンスが向上します。

松葉杖

レッドゾーンにいて、この種の低レベルの違いを見つけた場合、実際にはほとんどの場合、オプティマイザーの実装の違いです（上記のケースの多くは実際に同じように機能するはずです）。 ただし、ハッキングは一時的なパッチであり、プロジェクトの基盤ではありません。







原則として、それらは下のレイヤーの問題を示します。下のレイヤーは実際にはより健全なパフォーマンスモデルを提供する必要があるためです。 さまざまな低レベルのゲームについて報告されるレポートを聞いた場合、即時のアクションのガイドとして受け取らないでください。 このレポートは、非常にタイトになった場合にいつか必要になる可能性のあるハッキングのコーパスを構築するのに役立ちます。

例

JDK 9で最近見つかった非常に簡単な例があります。







JavaにはArrayList型があり、内部クラスItrを介して実装される反復子があります。 このItrクラスはプライベートなので、Itrコンストラクターを呼び出すことができるように、合成のいわゆるbridgeメソッド（パブリック）があります。 問題は、Itrを呼び出すと、このメソッドのシグネチャにまだロードされていないクラスが表示されるため、ホットスポットインレイヤーが破損することです。



このエラーはどこにありますか（最適化中）？ これはArrayListコードのエラーですか？ むしろ、いいえ。 これはjavacコードのバグですか？ はい、そうです。 ホットスポットコードでの最適化が不十分ですか？ むしろ、はい。 しかし、コンパイラーが気づき、コンパイラーでこれを修正する方法を理解するまで、ArrayListに直接入れる方が簡単です。







したがって、引数のないこのようなコンストラクターがそこに作成され、バグへのリンクがそこに書き込まれ、このコンストラクターが作成される理由などが示されます。

訂正

レッドゾーンを長時間掘り下げると、通常、人々があなたのところに来て「すぐに飛び込もうとすると、すべてが自分を傷つけます」と言います。 メンタルトラップは非常に単純です。彼らは、ハックをすぐに回せば素晴らしいと思います。







練習では、レッドゾーンでは「傷」が発生しないことが示されています。

例として（私は彼を常に見ています）：









JDKでパフォーマンスの問題が見つかりました。 JDKで修正する代わりに、次のように言いました。 Unsafeを介してハッキングします。」 そして、Unsafeがなくなっており、setAccessible（）でさえ機能していないことがわかりました。 したがって、だまされてはいけません。 レッドゾーンで作業する場合、技術的負債を負担します。









ハックが何のために行われたのか、どのような条件下でそれが適用されるのか、それがもはや必要でないことを確認する方法、あなたが待っているアップストリームのバグなどを常に文書化します。



私は学校での学校生活の授業で止血帯を作るように教えられました。 私は今でも、血の鞭の色に応じて、この止血帯を傷の上または下に適用するというこの指示を思い出します。 しかし、私は命令の別の段落のために思い出します：あなたの同志の身体に止血帯を置いた後、あなたはそこにタイムスタンプ付きのメモを置くべきです。



コードにこのようなハックを作成するたびに、特定のストーリーが頭の中にあります。コードのひどい箇所に止血帯を置き、そこに何らかの理由でそれが行われたことを書く必要があります。バグ、およびこのハーネスは、そのような条件が満たされた場合にのみ削除できます。 これにより、私または他の同僚がこのコードを発見したときに、すぐに切り取る価値があるかどうかを理解する機会が得られます。または、止血帯を削除すると、プロジェクトの残りの部分（または仲間）が殺されます。

レッドゾーンの小計

ハッキングを禁止しません。 これについて警告するのは愚かなことです。とにかくそれらを行うでしょう。 ただし、プロジェクトでハッキングの数と密度を維持することは、その存続に必要な条件です。



アップストリームと連携する機能（たとえば、上記のリポジトリに変更をコミットしてオープンソースに取り組んでいる場合）は、長期的な運命を大いに促進します。 パッチを適用した内部製品がアップストリームから分岐するほど、それをサポートするのに費用がかかります。



これらのすべての層を理解する能力は、「猫で」正常に訓練されます。おそらく、あらゆる種類の重要な変更を実行できるステージング環境が必要です。

別れの言葉

しかし、ここで私たちは筋金入りの会議です。 このすべての富で何をしようか？

筋金入りの会議に参加していて、製品のユーザーである場合、生産性に携わる人としての私の観点からは、次のことを行う必要があります。

• レッドゾーンからのハッキングの適用可能在庫を更新します。 プロダクションに実装すべきレッドゾーンからのハッキングをすぐに書き始める必要はありませんが、この辞書を更新するだけです。
  
  
• 共犯者を見つけ、黄色で作業するためのアプローチについて話し合います。 より正確にプロファイルおよび監視する方法などについて。
  
  
• または、イエローゾーンからグリーンゾーンに引き継がれるトリック、つまり 生産性のために複雑さを交換するために使用していたと思われていたものは、現在では単なる標準的なコード記述の練習です。
  
  

製品開発者の場合：

• ユーザーがイエローゾーンで作業するためのアプローチについて議論するのに役立ちます-プロファイル方法、監視方法など。
  
  
• そして、人々が絶えず遭遇するレッドゾーンからのハックが、イエローゾーンまたはグリーンゾーンのいずれかにドラッグする価値があるかを理解します。
  
  

主なパフォーマンス作業はグリーンゾーンで行われることに注意してください。 プロジェクトの生産性を高めるたびに、まず簡単なことを見てください。 排気性能が向上します。 それは退屈なので、誰も会議でそれらについて話すことはありません。 彼らは通常、黄色または赤色のゾーンについてあなたに話します。 誰かがLinkedListをArrayListに英雄的に交換した方法について、通常は誰も話さないでしょう。

---

Joker 2017では、Aleksey Shipilevが「Shenandoah：可能性のあるガベージコレクター（パート2）」という新しいレポートを提供し、Shenandoahのような低速GCが直面しなければならない問題と、JVMレベルで何ができるかについて話します。 会議はサンクトペテルブルクで11月3日と4日に開催されます。 プログラムと他のレポートの発表はイベントの公式ウェブサイトにあります 。