タグ付けされた質問 「optimization」

私の同僚は今日、と呼ばれるクラスをコミットしましたThreadLocalFormat。これは基本的にJava Formatクラスのインスタンスをスレッドローカルに移動します。これらはスレッドセーフではなく、作成するには「比較的高価」です。簡単なテストを作成し、1秒間に200,000個のインスタンスを作成できると計算し、その数を作成するように彼に尋ねました。彼は優れたプログラマーであり、チームの全員が高度なスキルを持っているため、結果のコードを理解するのに問題はありませんが、実際に必要のない場所を最適化する場合でした。彼は私のリクエストに応じてコードをバックアウトしました。どう思いますか？これは「時期尚早な最適化」のケースですか？それは実際にどれほど悪いですか？

215 design  optimization  architecture 

最近、PHPでisset（）がstrlen（）よりも高速だった理由を調べるために、Stack Overflowについて質問しました。これにより、読み取り可能なコードの重要性と、コードのマイクロ秒のパフォーマンスの改善が考慮に値するかどうかについて疑問が生じました。 私の父は退職したプログラマーであり、私は彼に応答を示しました。彼は、コーダーがマイクロレベルでもコードのパフォーマンスを考慮しない場合、優れたプログラマーではないことを完全に確信していました。 確かではありません-おそらく計算能力の向上は、この種のマイクロパフォーマンスの改善を考慮する必要がなくなったことを意味しますか？おそらく、この種の検討は実際の言語コードを書く人次第でしょうか？（上記の場合のPHPの）。 環境要因が重要になる可能性があります-インターネットは世界のエネルギーの10％を消費します。何百万ものウェブサイトで何兆回も複製されると、数マイクロ秒のコードがどれだけ無駄になるのだろうか？ できればプログラミングに関する事実に基づいて答えを知りたいです。 コーディングの際にマイクロ最適化は重要ですか？ 25の答えの私の個人的な要約、すべてに感謝します。 非常にまれな状況でのみ、マイクロ最適化について本当に心配する必要がある場合があります。ほとんどの場合、信頼性と読みやすさがはるかに重要です。ただし、ときどきマイクロ最適化を検討しても害はありません。基本的な理解は、次のようなコーディングの際に明らかに悪い選択をしないようにするのに役立ちます。 if (expensiveFunction() || counter < X) あるべき if (counter < X || expensiveFunction()) （@ zidarsk8の例）これは安価な関数である可能性があるため、コードを変更するとマイクロ最適化になります。しかし、基本的に理解していれば、そもそも正しく書くことができるので、その必要はありません。

178 code-quality  performance  optimization 

既存のコードを拡張/改善する必要がある状況に陥ることがあります。古いコードは非常にスリムですが、拡張するのも難しく、読むのに時間がかかります。 それを最新のコードに置き換えるのは良い考えですか？ 少し前に私は無駄のないアプローチが好きでしたが、今では、より高い抽象化、より良いインターフェース、より読みやすく拡張可能なコードのために多くの最適化を犠牲にするほうが良いように思えます。 コンパイラも同様に良くなっているように見えるので、何も言わずstruct abc = {}にmemsetsに変わり、shared_ptrsは生のポインタをいじるのとほぼ同じコードを生成します。 それでも、スタックベースの配列や、いくつかのあいまいなロジックを持つ古いC関数が表示されることがありますが、通常はクリティカルパスにありません。 どちらかの方法でコードの一部に触れる必要がある場合、そのようなコードを変更することは良い考えですか？

78 c++  c  refactoring  optimization  maintainability 

「時期尚早の最適化はすべての悪の根源」は、私たちのほとんどすべてが聞いたり読んだりしたものです。どのような最適化が時期尚早ではないか、つまりソフトウェア開発のすべての段階（高レベル設計、詳細設計、高レベル実装、詳細実装など）でどのような最適化がどの程度最適化されるのかを知りたいのですが、それはダークサイドに渡ることはありません。

75 optimization 

C / C ++ページの多くの質問と回答、具体的または間接的にマイクロパフォーマンスの問題（間接関数と直接関数とインライン関数のオーバーヘッドなど）、またはO（N 2）vs O（N log N）アルゴリズムの使用100アイテムのリスト。 私は、問題がない限り、または問題があることがわかるまで、常にマイクロパフォーマンスを気にせず、マクロパフォーマンスにほとんど気を配らずに、コーディングしやすく、信頼性の高いコードを維持します。 私の質問は、なぜ多くのプログラマーがそんなに気にするのかということです。それはほとんどの開発者にとって本当に問題なのでしょうか、それについてあまり心配する必要がないほど幸運だったのでしょうか、それとも私は悪いプログラマーですか？

71 c++  c  optimization  code-organization 

ウィキペディアによると、プログラム最適化の90/10ルールは、「プログラムの実行時間の90％がコードの10％の実行に費やされる」と述べています（ここの2番目の段落を参照）。 私はこれを本当に理解していません。これはどういう意味ですか？実行時間の90％をコードの10％だけを実行するために使用するにはどうすればよいですか？では、コードの他の90％はどうでしょうか？わずか10％の時間でどのように実行できますか？

67 optimization  theory  program 

コードを書くときは、コードをできる限りクリーンで読みやすいものにするように常に心がけています。 ときどき、ラインを越えて、すっきりしたきれいなコードから少しugいコードに移行して、より速くする必要があるときがあります。 その線を横切るのはいつですか？

67 performance  optimization  quality  readability  maintainability 

私たちはされていることが多い語ったが、これは真実ではない、ハードウェアは、プログラムがそれだけでコンパイルされたバイナリコードを見ているように書かれている言語を気にしないこと。たとえば、謙虚なZ80を考えてみましょう。8080命令セットへのその拡張には、C-スタイル（NULLで終了する）文字列をスキャンするのに役立つCPIRなどの命令が含まれますstrlen()。設計者は、Cプログラムの実行（文字列の長さがヘッダーにあるPascalとは対照的に）が、設計で使用される可能性が高いことを特定している必要があります。別の古典的な例は、Lisp Machineです。 他にどんな例がありますか？たとえば、特定のプロセッサが特定の言語の規則を好むようにする命令、レジスタの数とタイプ、アドレス指定モードはありますか？私は特に同じ家族の改訂に興味があります。

44 language-design  history  optimization  hardware  assembly 

これは、私がゲーマーとして面白いと思った主題に関する一般的な質問です：CPU / GPUのボトルネックとプログラミング。間違っていなければ、CPUとGPUの両方が計算を行うことを理解するようになりましたが、アーキテクチャの違いにより、ある計算では他の計算よりも優れていることがわかりました。たとえば、クラッキングハッシュまたは暗号通貨マイニングは、CPUよりもGPUの方が効率的であると思われます。 だから私は疑問に思った：CPUが50％（例えば）である間、100％の負荷でGPUを持っていることは避けられない？ または、より正確に：最初に1つが100％の負荷である場合、GPUによって通常行われるいくつかの計算はCPUによって行われ、両方とも100％の負荷に達することができますか？ 私はこの主題について少し検索しましたが、かなり手ぶらで戻ってきました。これがこのサブセクションに位置し、あなたが私に与えるかもしれないどんな文書や講義にも開かれていると思います！

43 performance  optimization  cpu  gpu 

Goは、「金属に近い」状態で実行されるはずの数少ない言語の1つです。つまり、コンパイルされ、静的に型指定され、VMなしでネイティブにコードを実行します。これにより、Java、C＃などよりも速度が向上します。ただし、Javaの背後にあるようです（プログラミング言語のShootoutを参照） 成熟度の低いコンパイラがこれに大きな責任を負っていると仮定していますが、他の理由はありますか？Goの設計に固有のものはありますか。たとえば、Javaよりも速く動作することを妨げるものはありますか。私はランタイムモデルについて非常に洗練された見方をしていますが、少なくとも原則として、ネイティブコードの実行のおかげで、Javaよりも速く実行できるはずです。

39 language-design  optimization  go 

コードがどれだけ効率的でコードの可読性を犠牲にすべきですか？ たとえば、3行のコードを1行にまとめます。 私は読んでコードクラフト可読性が鍵であることをピートGoodliffeで。 あなたの考え？

37 code-quality  performance  optimization  readability 

CやC ++などのコンパイル言語用のジャストインタイムコンパイラはありますか？（頭に浮かぶ最初の名前はClangとLLVMです！しかし、私は彼らが現在それをサポートしているとは思いません。） 説明： このソフトウェアは、CやC ++などのコンパイルされたマシン言語でも、ランタイムプロファイリングフィードバックと、実行時のホットスポットの積極的に最適化された再コンパイルの恩恵を受けると思います。 プロファイルに基づく最適化も同様の仕事をしますが、異なる環境ではJITがより柔軟になります。PGOでは、リリースする前にバイナリを実行します。リリース後、実行時に収集された環境/入力フィードバックは使用されません。そのため、入力パターンが変更された場合、パフォーマンスの低下が発生します。しかし、JITはそのような状況でもうまく機能します。 ただし、JITコンパイルのパフォーマンス上の利点がそれ自体のオーバーヘッドを上回るかどうかについては議論の余地があると思います。

33 c++  performance  compiler  optimization  jit 

私はhttps://stackoverflow.com/q/11227809/555690から分岐予測に関する一般的な答えを読んでいたのですが、私を混乱させる何かがあります： あなたが正しく推測した場合、それは続けます。 あなたが間違っていると推測した場合、船長は停止し、後退し、スイッチを入れるように叫びます。その後、他のパスで再起動できます。 毎回正しいと思うなら、、列車は停止する必要はありません。 間違った推測をしすぎると、列車は停止、バックアップ、再起動に多くの時間を費やします。 しかし、これは私が得られないものです：あなたの推測が正しかったか間違っているかを知るには、とにかく状態チェックを行わなければなりません。どちらの方法でも同じ条件チェックを実行している場合、分岐予測はどのように機能しますか？ 私が言おうとしているのは、とにかく同じ条件チェックを行っているので、分岐予測はまったく分岐予測がないこととまったく同じではないということです。（明らかに私は間違っていますが、わかりません）

30 optimization 

これはC ++標準では必須ではありませんが、たとえばGCCが純粋な抽象クラスを含む親クラスを実装する方法は、問題のクラスのすべてのインスタンス化にその抽象クラスのvテーブルへのポインタを含めることです。 当然、これは、このクラスのすべてのインスタンスのサイズを、それが持つすべての親クラスのポインターによって膨張させます。 しかし、多くのC＃クラスと構造体には、基本的に純粋な抽象クラスである多くの親インターフェイスがあることに気付きました。sayのすべてのインスタンスがDecimal、さまざまなインターフェースすべてへの6つのポインターで肥大化していた場合、私は驚くでしょう。 それで、C＃がインターフェースを異なる方法で実行する場合、少なくとも典型的な実装では、どのようにインターフェースを実行しますか（標準自体はそのような実装を定義しないかもしれません）。また、純粋な仮想親をクラスに追加するときに、C ++の実装にオブジェクトサイズの膨張を回避する方法がありますか？

27 c#  c++  interfaces  optimization  abstract-class 

私は、一般的な英語の意味で「最適化」とみなされるものに対して独断的に多くの人々に出会いました。そして、彼らは非常にしばしば「部分的な」引用「早すぎる最適化はすべての悪の根源」です彼らのスタンスの正当化として、私が話していることは何でも「時期尚早の最適化」であると解釈することを意味します。しかし、これらのビューは非常に馬鹿げているため、最も純粋な「単純な」実装からのあらゆる種類のアルゴリズムまたはデータ構造の逸脱、または少なくとも以前のやり方からの逸脱を排除します。「パフォーマンス」や「最適化」について聞いてからシャットダウンした後に再び「耳を開く」ように、このような人々にどのようにアプローチできますか？「この男は10行のコードに2週間を費やしたい」とすぐに思わせることなく、パフォーマンスに影響を与える設計/実装のトピックについて議論するにはどうすればよいですか。 さて、「すべての最適化は時期尚早ので、悪である」かどうかのスタンスがいるすでにここにカバーされてだけでなく、ウェブの他のコーナーで、すでに議論されている最適化は時期尚早ので、悪の場合に認識する方法が、残念ながら、現実の世界には、反最適化への信仰への挑戦に対してあまり開かれていない人々がまだいます。 以前の試み 数回、「時期尚早の最適化は悪い」↛「すべての最適化は悪い」と説明するために、ドナルドクヌースから完全な引用を提供しようとしました。 私たちは小さな効率を忘れてはなりません。約97％の時間です。早すぎる最適化はすべての悪の根源です。しかし、その重要な3％でチャンスを逃してはなりません。 しかし、見積もり全体を提供するとき、これらの人々は実際に、私がやっていることはPremature Optimization™であると確信し、耳を傾けて拒否します。それはまるで「最適化」という言葉が彼らを怖がらせるかのようです：数回、「optimiz（e | ation）」という言葉の使用を単に避けることで、拒否されずに実際のパフォーマンス改善コードの変更を提案することができました（ 「パフォーマンス」も同様です-その言葉も怖いです）代わりに、「代替アーキテクチャ」や「改善された実装」のような表現を使用しています。このため、これは本当に独断的であり、実際に私が言うことを批判的に評価し、それを不要であるか、費用がかかりすぎると却下するのではないようです。

26 performance  teamwork  optimization  communication