デザインパターンを使用するとJavaコードが遅くなりますか? 追加のインターフェイスと構文構造 (クラス ラップなど) を使用すると、よく整理されたコードになりますか、それともコードが大幅に遅くなることはありませんか?
1398 次
7 に答える
11
これにより、コードが大幅に遅くなることはありません。一部の関数呼び出しは追加のクラスまたはメソッドにラップされるため、一部のメソッド呼び出しは少し遅くなりますが、人間はこれに気付かないでしょう。ナノ秒程度です。読みやすく再利用可能なコードの利点を常に優先します。
私は高性能アプリケーションです。パターンに基づいて設計および実装した後、コードをより高いパフォーマンスにリファクタリングすることを検討する必要があります。しかし、通常これは必要ありません。
そしていつものように、それは使用されるパターンとプログラムのユースケースに依存します。
于 2012-10-06T12:09:36.377 に答える
4
あなたの考えに従えば、Java は抽象化層でいっぱいなので、正確で保守しやすいコードを書くのがより便利になりますが、その速度はアセンブラーや C の速度よりも低くなります。ラッパーがコードを大幅に遅くしている場合、Java よりも C の方が適しているユース ケースがある可能性があります。
一方で、オーバーエンジニアリングをしたり、コードに見られるすべての問題に対して大量のパターンを投入したりしないように注意する必要があります。パターンが理論的に適合すると思われる場所だけでなく、利点が明確にわかるパターンを慎重に使用してください。
私が好むコーディングの方法は、まず、差し迫った問題を解決する最も単純で馬鹿げたソリューションを作成することです。後で、コードの重複やその他のコードのにおいが発生するような類似の関数を 1 つまたは 2 つ追加する必要がある場合にのみ、適切なパターンの導入を検討します。
于 2012-10-06T12:24:48.927 に答える
1
インターフェイスは、コードをより明確にし、将来の変更を容易にしますが、コードがどのように適合するかをコンパイラに伝えるためだけに存在するため、速度には影響しません。
設計パターン パターンは、一般的な問題に対する一般的なソリューションです。問題がある場合は、よく知られている解決策のいずれかを使用してください。それはあなたのプログラムを遅くしますか？それは、利用可能なソリューション間で行う選択によって異なります。選択するためには、各パターンのトレードオフを理解する必要があります。
しかし、デザイン パターン ソリューションを使用しないと、独自の DIY ソリューションを使用することになります。これを行うと、通常、問題を解決することはできません。または、(私たちの時間と機械の時間で) できるだけ早く解決することも、将来のメンテナンスのために当然のことながら解決することもできません。この最後のポイントは、デザイン パターンによって、問題と解決策について話す新しい方法が得られるからです。その新しい語彙を理解すると、より複雑な問題をより簡単に解決できるようになります。
それで、それらはあなたのプログラムを遅くしますか？いいえ、彼らはそれを機能させます。もっと早く。
パターンの読み取りをお楽しみください。実際に解決すべき問題がある場合、それらはより理にかなっています。
于 2012-10-06T12:35:48.593 に答える
0
前に述べたように、デザイン パターンを使用するオーバーヘッドは取るに足らないものです。確かに、Android のようにパフォーマンスが必要とされる一部の Java プロジェクトのコード ソースを見てみると、それらすべてがデザイン パターンを多用していることに驚かれることでしょう。パターン。
ただし、マップがより適しているハッシュマップの代わりにリストを使用することを選択するなど、一部の設計上の選択はパフォーマンスに影響を与える可能性があります。
于 2012-10-06T12:24:43.137 に答える
0
理想的には、許可されたプログラミング構造を使用する場合、パフォーマンスについて心配する必要はありません。JVM は、コードを最適化するのに優れています。ほとんどのパフォーマンスの問題は、通常、スレッド同期に関連するコードを記述するコード、および DB 呼び出しなどの I/O を行うコードによって発生します。設計をモジュール化してきちんとしたものにするために、余分なインターフェースやクラスがほとんどなくても問題はありません。リフレクションやその他の高度な機能の使用に依存する独自のフレームワークを作成する場合は、少し注意が必要になる場合があります。最適化されていない場合、パフォーマンスのボトルネックが追加される危険性があります。
于 2012-10-06T12:25:28.050 に答える
0
ほとんどの場合、コードのラッピングを追加すると、コードが少し遅くなります。しかし、場合によっては、これは真実ではありません。10 億回を超える反復を繰り返すと、追加のラッピングが大幅に遅くなる可能性があります。グッド プラクティスは、最初に読みやすく再利用可能なコードを作成することです。その後、コードのプロファイリングと最適化を試みて初めて、パフォーマンスが最悪になります。多くの場合、計算アルゴリズムを変更する必要がありますが、回避策のコードを記述する必要がある場合もあります。
于 2012-10-06T12:33:08.767 に答える
0
多分。いつものように、トレードオフに関しては簡単な答えはありません。
特定のパターンを使用するとコードがより明確になることがわかりましたが、パフォーマンスが低下する可能性があります。それで、あなたは何をしますか？あなたは最善の判断を下します。多くの場合、最初にパターンを試してから、それが十分に高速かどうかをテストし、必要に応じて最適化します。可能な限り高速にする必要があること、または逆に、コードがパフォーマンスに重要ではないことを既に知っている場合があります。
于 2012-10-06T12:49:54.160 に答える