小さなオブジェクトの作成を最小限に抑える必要がありますか？

多数の（1000を超える）小さなオブジェクトを頻繁に作成するものを作成する場合、パフォーマンスのためにそれを最小化する必要がありますか？特に、ローエンドからハイエンドのデスクトップ、さらにはモバイルまで、どのシステムで実行されるかわからない場合。モバイルの場合、多くのオブジェクトを作成するとパフォーマンスが少し低下すると聞きましたが、それがどれほど本当かはわかりません。

この考えをよく示す例があります。グラフィックプログラムでは、理想的にはと呼ばれるすべての描画に使用されるメソッドがあるとしましょうdrawPixel(Point)。1秒間に60回以上呼び出される可能性のあるゲームのように、作成されるポイントは1000になり、頻繁に繰り返される場合があります。または、drawPixel(int x, int y)多くのポイントオブジェクトの作成を最小限に抑えるために使用できます。

オブジェクト指向の設計では、Pointを使用することをお勧めします。ただし、プリミティブ型を使用するとパフォーマンスが向上する場合があります。ほとんどの場合、パフォーマンスの向上はごくわずかですが、モバイルマシンや古いマシンなどについてはよくわかりません。このようなことを行うことによるパフォーマンスの向上は何ですか？それは考慮に入れられるべきものですか？

一般に、いいえ、パフォーマンスの低下を恐れてオブジェクトの作成を避けるべきではありません。これにはいくつかの理由があります。

1. オブジェクトの使用は、Javaを使用するポイントの一種です。それらを先制的に回避することは、Javaを使用するという決定が、そもそも正しい決定ではなかったかもしれないという兆候です。
2. パフォーマンスの問題を予測することは非常に困難です。何かがボトルネックであると思い込まないでください。常に測定します。ほとんどの場合、パフォーマンスエンジニアリングは、適切な場所に小さな変更を加えることです。実験せずに薬の効果を予測できる以上に測定せずに正しい場所を予測することはできません。
3. オブジェクト作成のコストは大幅に見積もられています。最近のJVMでは、基本的にはポインターをインクリメントすることになります（世代別ガベージコレクターでは、管理コストもわずかです）。オブジェクトを回避したり、オブジェクトプーリングを使用したりすることを勧めるテキストがインターネット上にたくさんあります。このアドバイスは1990年代に時々正しかったです。今日それはほとんど時代遅れです。オブジェクトを回避したり、オブジェクトを自分で管理したりすることで発生する追加の開発コストと複雑さを正当化するのに十分なパフォーマンスを得る可能性はほとんどありません。

とはいえ、何かをオブジェクトにすることは、そもそも理にかなわないところがあります。描画ルーチンに2つの座標を渡すのはそのような場合です。座標ペアには独立した存在がなく、IDがなく、一度しか使用されず、すぐに破棄されます。

その場合は、intオブジェクトにラップするのではなく、2つのを渡します。OOPの要点は、すべてがオブジェクトでなければならないということではありません。重要なのは、オブジェクトはデータ表現の問題に対する自然な解決策である場所での開発を容易にするということです。意味のあるオブジェクトは避けないでください。そうでないオブジェクトを導入しないでください。

コードを書く前にパフォーマンスへの影響を検討するときは、自分が何をしているのか分からないと想定する必要があります。

Javaとプリミティブでは、オブジェクトのスペースのオーバーヘッドが非常に小さくなります。オブジェクトが小さいほど、オーバーヘッドのパーセンテージは大きくなります。しかし、私はずっと前に、nを2倍にすることはnをn倍することに比べて何もないことを学びました。

ですから、はい、サイズの影響が半分または4分の1のシステムを試してみることができますが、本当に気にする理由を自問してください。この問題に対する複雑な解決策は、あまり受け入れられないでしょう。特にそのようなコードに飛び込むのは混乱するでしょう。混乱したプログラマーは悪いコードを書きます。それらはn log nコードであるべきn回nコードを書き込みます。そして、彼らはそれを行うのにより長い時間がかかります。

さて、私が話すことができるほとんどの時間内を見る必要がない素敵なボックスに収まるトリックでスペースを節約できたら。それがボックスである場合、そのボックスがよりうまく機能するときに別のボックスと交換できます。

私が行ったパフォーマンスチューニング（例）では、メモリ管理が大きな原因であるのは非常に簡単です。新しい演算子とガベージコレクターがどれほど狂っているかは気にしません。最速の計算は計算なしです。したがって、メモリマネージャーがかなりの時間を費やし、オブジェクトの作成を避けられないことがわかった場合は、常に新しいオブジェクトを作成するのではなく、オブジェクトを再利用する方法を見つけます。

これは、オブジェクトを作成する必要がある場合にのみ行います。グラフィックについては、通常はしません。IMHO、グラフィックがしなければならない描かれた、ではないに構築します。確かに、画像は点、点を結ぶ線、ポリゴン、テキストなどで構成されていると言えます。それはあなたがそれらを描く前にそれらからオブジェクトを作ることに代わるものがないという意味ではありません。描くだけです。

Paintメソッドがあります。それをオーバーライドして、すべてをビットマップに描画し、それを画面にブロック転送します。瞬間的に見えます。マウス入力の場合、オーバーライド、クリック、ドラッグなどを検出するメソッドがあります。

OOPは、特定の理由で良い考えです。これらの理由は、すべての状況に当てはまるわけではありません。

先に進んで、小さな割り当てを使用してください。最新のメモリマネージャ、特に高度に最適化されたJavaオブジェクトマネージャは非常に効率的です。動作中のプログラムの主要なパフォーマンス最適化を保存します。

全体的なパフォーマンスが十分である可能性は非常に高いです。あなたはそうではありませんことが判明した場合、その後、だけにして、コードのパフォーマンスをプロファイリング。ソフトウェア開発の長いキャリアの中で、私はボトルネックが予想される場所にほとんどないことを学びました。

私はかつて、チームメンバーにオブジェクトメンバーの検索を20倍速くするために数日間費やしてもらいました。成功！ただし、実際に使用した場合の最高の全体的なスピードアップは、100分の1パーセントで測定されました。スピードアップには、メンバーごとのメモリ割り当てを大きくする必要があったため、変更はすぐに取り消されました。

それは簡単です。1000個の小さなオブジェクトが必要な場合は、1000個の小さなオブジェクトを作成し、それについて心配する必要はありません。100個の小さなオブジェクトが必要な場合、1000個の小さなオブジェクトを作成するのはばかげています。必要なものだけを作成してください。

パフォーマンスが心配な場合（およびパフォーマンスも心配されていない場合）、1か所に1 度だけ記述された機能を使用すると、コード全体がよりシンプルで理解しやすくなります。次に、パフォーマンスの問題がある場合、測定により、パフォーマンスの問題が発生する場所が1つあることがわかります。これにより、状況が簡単になり、変更が必要な場所が1つだけになります。または、測定により、この1つの場所が問題を引き起こさないことがわかったので、完了です。