多数の小さなオブジェクトの作成を最小限に抑える必要がありますか？
多くの（1000を超える）小さなオブジェクトを頻繁に作成するものを作成する場合、パフォーマンスのためにそれを最小化する必要がありますか？特に、ローエンドのデスクトップからハイエンドのデスクトップ、さらにはモバイルまで、どのシステムで実行されるかわからない場合。モバイルの場合、多くのオブジェクトを作成するとパフォーマンスが少し低下すると聞きましたが、それがどれほど本当かはわかりません。
このアイデアをよく示す例があります。グラフィックプログラムで、理想的にはdrawPixel(Point)と呼ばれるすべての描画に使用されるメソッドがあるとしましょう。 1秒間に60回以上呼び出されるゲームのように、1000のポイントが作成され、それが頻繁に繰り返される場合があります。または、drawPixel(int x, int y)を使用して、多くのPointオブジェクトの作成を最小限に抑えることができます。
オブジェクト指向の設計では、Pointを使用することをお勧めします。ただし、プリミティブ型を使用するとパフォーマンスが向上する場合があります。パフォーマンスの向上はほとんどの場合ごくわずかですが、モバイルマシンや古いマシンなどについてはよくわかりません。このようなことを行うことによるパフォーマンスの向上は何ですか？それは考慮に入れられるべきものですか？
一般に、noは、パフォーマンスの低下を恐れてオブジェクトを作成することを避けるべきではありません。これにはいくつかの理由があります。
- オブジェクトの使用は、Javaを使用するポイントの一種です。それらを先制的に回避することは、Javaを使用する決定が、最初から適切なものではなかった可能性があることを示しています。
- パフォーマンスの問題は、悪名高い予測が困難です。 決して何かがボトルネックであると仮定します。 常にメジャー。パフォーマンスエンジニアリングは、ほとんどの場合、適切な場所に小さな変更を加えることです。実験せずに薬の効果を予測できる以上に測定せずに正しい場所を予測することはできません。
- オブジェクト作成のコストは大幅に見積もられています。最近のJVMでは、基本的にはポインターをインクリメントすることになります（世代別ガベージコレクターでは、管理コストもごくわずかです）。インターネット上には、オブジェクトを回避したり、オブジェクトプーリングを使用したりするようにアドバイスするテキストがたくさんあります。このアドバイスは、1990年代に時々正しかったです。今日それはほとんど時代遅れです。オブジェクトを回避したり、自分で管理したりすることで生じる追加の開発コストと複雑さを正当化するのに十分なパフォーマンスを得る可能性はほとんどありません。
とはいえ、何かをオブジェクトにしても、そもそも理にかなわないところもあります。 2つの座標を描画ルーチンに渡すのはそのような場合です。座標ペアには独立した存在がなく、IDがなく、一度だけ使用され、すぐに破棄されるなどです。
その場合は、オブジェクトにラップするのではなく、2つのintを渡してください。 OOP=のポイントは、すべてがオブジェクトである必要があるということではありません。ポイントは、オブジェクトがデータ表現の問題に対する自然な解決策である場所での開発を容易にすることです。彼らは理にかなっている-彼らがいない場所でそれらを紹介しないでください。
私が行ったパフォーマンス調整では（ example ）、メモリ管理が大きな原因であるのは非常に簡単です。彼らがnew演算子とガベージコレクターをどれほど狂ってチューニングしたかは気にしません。最速の計算は計算なしです。したがって、メモリマネージャーにかなりの時間がかかり、オブジェクトの作成を避けられない場合は、常に作成するのではなく、オブジェクトを再利用する方法を見つけます。新しいもの。
これを行うのは、オブジェクトを作成する必要がある場合のみです。グラフィックについては、通常はしません。私見、グラフィックスは構築ではなく描画である必要があります。もちろん、画像は点、点を結ぶ線、ポリゴン、テキストなどで構成されていると言えます。 描画する前に、オブジェクトからオブジェクトを作成する方法がないという意味ではありません。描くだけです。
Paintメソッドがあります。それをオーバーライドして、すべてをビットマップに描画し、それを画面にブロック転送します。瞬間的に見えます。マウス入力の場合、オーバーライド、クリック、ドラッグなどを検出するメソッドがあります。
OOPは、特定の理由で良い考えです。これらの理由は、すべての状況には当てはまりません。
先に進んで、小さな割り当てを使用してください。最新のメモリマネージャー、特に高度に最適化されたJavaオブジェクトマネージャー）は非常に効率的です。作業プログラムのパフォーマンス最適化を大幅に節約できます。
全体的なパフォーマンスが十分である可能性は非常に高いです。そうでないことがわかった場合は、and only thenで、コードのパフォーマンスのプロファイルを作成します。ソフトウェア開発の長いキャリアの中で、私はボトルネックが予想される場所にはほとんどないことを学びました。
私はかつて、チームメンバーにオブジェクトメンバーの検索を20倍速くするために数日間費やしてもらいました。成功！ただし、実際に使用した場合の最高の全体的な速度向上は、100分の1パーセントで測定されました。スピードアップには、メンバーごとのより大きなメモリ割り当てが必要だったため、変更はすぐに取り消されました。
コードを書く前にパフォーマンスへの影響を検討するときは、自分が何をしているのか分からないと想定する必要があります。
Java対プリミティブのオブジェクトのスペースオーバーヘッドは非常に小さいです。オブジェクトが小さいほど、オーバーヘッドのパーセンテージは大きくなります。しかし、nを2倍にするものはnにnを乗算するものに比べて何もありません。
ですから、はい、サイズの影響が半分または4分の1のシステムを試してみることができますが、本当に気にする理由を自問してください。この問題に対する複雑な解決策は、あまり受け入れられません。特に、そのようなコードに飛び込むのは混乱を招くためです。混乱したプログラマーは悪いコードを書きます。それらはn log nコードであるべきn回nコードを書き込みます。そして、彼らはそれを行うのにより長い時間がかかります。
さて、私が話すことができるほとんどの時間内を見る必要がない、Niceボックスに収まるトリックを使ってスペースを節約できたら。それがボックスである場合、そのボックスがよりうまく機能するときに別のボックスと交換できます。
それは簡単です。1000個の小さなオブジェクトが必要な場合は、1000個の小さなオブジェクトを作成し、それについて心配する必要はありません。 need 100個の小さなオブジェクトの場合、1000個の小さなオブジェクトを作成するのは愚かです。必要なものを作成し、それ以上は作成しないでください。
パフォーマンスを心配している場合（およびパフォーマンスを心配していない場合）、機能が1か所にonceと記述されている必要があります。これにより、コード全体がよりシンプルで理解しやすくなります。次にifパフォーマンスの問題がある場合、測定により、パフォーマンスの問題が発生するoneの場所があることがわかります。これにより、問題が簡単になり、必要な場所は1つだけになります。それを変更します。または、測定により、この1つの場所は問題を引き起こさないことがわかったので、完了です。