optimization - 未知のもののために設計するときに最適化の危険を回避する方法は？

Question

2つのパートナー：

1）新しいタイプのアプリケーションを設計していて、概念とコンテンツを表現するための新しいアルゴリズムを考え出しているとしましょう。その段階で最適化手法を積極的に検討しないようにすることは理にかなっています。心の奥底で、何百万もの要素を超えるO（N！）になるのではないかと心配している場合はどうでしょうか。

2）もしそうなら、概念実証が実行されたら最適化できるかもしれないクールな機能を制限しないように言ってください-このプログラマーの生涯の習慣からどのように自分自身を止めますか？私はメンタルエクササイズや紙幣を試してきましたが、基本的にアセンブラーのクロックサイクルを数えて育ち、機能的な価値を十分に検討する前に、無駄すぎるという潜在的な解決策を拒否し続けています。

編集：これは、これまでに行われたことのないもの（未知のもの）を設計することです。理論的に行うことができるかどうかさえわからない場合は、手元にある無制限の計算能力を気にしないでください。したがって、「プロトタイプは確立されたコンピューティングの原則であるため、プロトタイプを作成する前に最適化する必要があります」という答えは特に有用ではありません。

score 6 · Accepted Answer

私はあなたがまだそれを知らないと思うからではなく、あなたがあなたの内なる批評家を抑圧している間道徳的なサポートを提供するために以下のすべてを言います:-)

重要なのは正気を保つことです。

スケーリングが期待されるTheta（N！）アルゴリズムを作成していることに気付いた場合は、気が狂っています。あなたはそれを捨てなければならないでしょう、それであなたはあなたが実際に使うかもしれないより良いアルゴリズムを今見つけ始めたほうがよいでしょう。

ユーザーのキーを押すたびに正確に1回実行されるPentiumコードのビットが、10サイクルまたは10Kサイクルかかるかどうかを心配している場合は、気が狂っています。CPUは95％アイドル状態です。それに1万回のわずかなサイクルを与えます。必要に応じて拡張チケットを発行しますが、アセンブラーからゆっくりと離れます。

プロジェクトが「研究プロトタイプを書いて、それを実際の製品に進化させる」か、「研究プロトタイプを書く」かを決めるのは一度です。明らかに、研究が成功すれば、別の関連プロジェクトが予定されていることを期待しています。

後者の場合（コメントからはあなたが持っているもののように聞こえます）、N <= 7でのみ機能し、それでもここからシンシナティへの電圧低下を引き起こすものを書く余裕があります。それはまだあなたができると確信していなかったことです。問題を感じたら、パフォーマンスの問題が何であるかをよりよく理解できます。

あなたがしていることは、今の時間の浪費（あなたの研究が無関係であることが証明されていることを考慮して）と後の時間の浪費（あなたが今重要であることが判明した何かを考慮しなかったため）のバランスをとることです。研究のリスクが高いほど、何かをするだけで幸せになり、後で何をしたかを心配する必要があります。

score 5 · Accepted Answer

私の大きな答えはテスト駆動開発です。すべてのテストを前もって作成することにより、探している動作を実装するのに十分なコードのみを作成するように強制します。タイミングとクロックサイクルが要件になる場合は、そのシナリオをカバーするテストを記述してから、それらの要件を満たすようにコードをリファクタリングできます。

score 2 · Accepted Answer

最適化は必ずしも危険ではありません。コードを書くときは、速度についてある程度考えることをお勧めします。これは、より単純で高速なものを実行するときに、低速で厄介なソリューションを実装することを妨げるためです。また、何かが実用的であるかどうかを頭の中でチェックすることもできます。

起こりうる最悪の事態は、最適化を明示的に無視して大規模なプログラムを設計することです。戻って、完全に書き直さないと最適化できないため、設計全体が完全に役に立たないことに気付くだけです。あなたがそれを書くときにすべてを考慮するならば、これは決して起こりません-そしてその「すべて」の一部は潜在的なパフォーマンスの問題です。

「時期尚早の最適化はすべての悪の根源です」はすべての悪の根源です。私は、この概念の乱用によってプロジェクトが機能不全に陥っているのを見てきました。私の会社には、ネットワーク上のディスクからトランスポートストリームをブロードキャストするソフトウェアプログラムがあります。もともとはテスト目的で作成されましたが（一度にいくつかのストリームが必要になるため）、後でビデオオンデマンドで使用できるように、より多くのストリームで機能することが常にプログラムの仕様要件に含まれていました。

速度を完全に無視して書かれているので、めちゃくちゃでした。必要になることはないはずなのに、大量のmemcpyがあり、TS処理コードが非常に遅い（実際にはすべてのTSパケットを複数回解析した）などです。一度に処理できるストリームは数千ではなく、わずか40であり、実際にVODに使用するときは、戻ってクリーンアップと大部分の書き換えに膨大な時間を費やす必要がありました。それ。

score 2 · Accepted Answer

セキュリティや使いやすさのように、パフォーマンスはプロジェクトの最初から考慮しなければならないものです。そのため、優れたパフォーマンスを念頭に置いて設計する必要があります。

score 2 · Accepted Answer

古いクヌースの行は、「私たちは小さな効率を忘れるべきです。たとえば、約97％の確率で、時期尚早の最適化がすべての悪の根源です。」O（N！）からO（poly（N））は、「小さな効率」ではありません。

タイプ1を処理する最良の方法は、機能する可能性のある最も単純なものから始めて（O（N！）は、数十の要素を超えてスケーリングしない限り機能しない可能性があります！）、アプリケーションの残りの部分からカプセル化することです。パフォーマンスの問題が発生することを想定して、より適切なアプローチに書き直すことができます。

score 2 · Accepted Answer

「まず走らせる。それから速く走らせる。」

また

「最初に終えるには、まず自分が終わらせなければならない。」

遅い既存のアプリは通常、超高速の存在しないアプリよりも優れています。

score 2 · Accepted Answer

まず第一に、人々は仕上げだけが重要であると主張します (またはほとんど)。

しかし、メインアルゴリズムが O(N!) の複雑さを持つ製品を完成させた場合、経験則として、それは完成していません! 99% のケースで不完全で受け入れられない製品があります。

妥当なパフォーマンスは、動作する製品の一部です。完璧なパフォーマンスはそうではないかもしれません。短いメモを書くのに 6 GB のメモリを必要とするテキストエディタを使い終えた場合、製品はまったく完成していません。時間を無駄にするだけです。製品を完成させることは、顧客/ユーザーのニーズを満たす能力を実現することです. それに失敗した場合、スケジュール内でコードの記述を完了したことは問題ではありません。

そのため、結果として役に立たない製品を回避するすべての最適化を検討し、残りの設計および実装プロセスに影響を与えないようになったらすぐに適用する必要があります。

score 1 · Accepted Answer

「積極的に最適化を考慮しない」というのは、私には本当に奇妙に聞こえます。通常、80/20の法則は非常にうまく機能します。ユースケースの20％未満でプログラムを最適化するために、時間の80％を費やしている場合、ユースケースの20％が本当に重要でない限り、時間を無駄にしない方がよい場合があります。

完璧主義に関しては、それがあなたを遅くし始め、あなたに時間枠を逃させない限り、それは何も悪いことではありません。コンピュータプログラミングの芸術は、アプリケーションの美しさと機能のバランスをとる行為です。時間管理の学習を検討するのに役立ちます。作業を分割して測定する方法を学ぶと、今すぐ最適化するか、作業バージョンを作成するかを簡単に決定できます。

score 1 · Accepted Answer

私はこの質問が好きなので、他の人がすでに回答しているにもかかわらず、回答します。

私が大学院にいたとき、MIT AI ラボでは、言語、ビジョン、学習、推論などを理解するためのプログラムを作成しようとして、常にこの状況に直面していました。

私の印象では、進歩した人は何かを速くするよりも、何か面白いことをするプログラムを書くことに興味を持っていました。実際、パフォーマンスについて心配するのに費やされた時間は、基本的に、興味深い行動を考え出すのに費やされた時間から差し引かれました。

今はもっと平凡なものに取り組んでいますが、同じ原則が当てはまります。何かが機能するようになったら、いつでもより速く機能させることができます。

ただし、現在のソフトウェアエンジニアリングの教え方は、モグラ塚から山を作ることを強く奨励していることに注意してください。人々は、単にそれを成し遂げるのではなく、サービス、インターフェース仕様、プラグイン、および太陽の下にあるすべてのものを使用して、できるだけ多くの抽象化レイヤーを使用して、クラス階層を作成するように教えられます。彼らは、これらのものをできるだけ控えめに使うように教えられていません。

その結果、非常に複雑なソフトウェアになり、変更がはるかに複雑になるため、最適化がはるかに困難になります。

これを回避する唯一の方法は、パフォーマンスチューニングを行って多くの経験を積むことであり、そのようにして、この過度の複雑さにつながる設計アプローチを認識するようになることだと思います。(例: クラスとデータ構造を強調しすぎる。)

一般的に教えられている方法で作成されたアプリケーションをチューニングする例を次に示します。

score 1 · Accepted Answer

onebyoneの回答に続いて、コードの最適化とアルゴリズムの最適化には大きな違いがあります。

はい、この段階では、コードを最適化することには疑問の余地があります。本当のボトルネックがどこにあるのかわからず、そもそも速度の問題が発生するかどうかもわかりません。

しかし、アルゴリズム/データ構造などの開発のこの段階でも、スケーリングの問題に注意することは合理的であるだけでなく、不可欠だと思います。宇宙の熱による死が起こる前に、光沢のある新しいアプリケーションを 1 回も実行できないことが封筒の裏側の分析で示されている場合、結局のところ、続行する意味はあまりありません。;-)

score 1 · Accepted Answer

アルゴリズムの O(N!) 最悪のケースを忘れるのはかなり理にかなっていると思います。まず、特定のプロセスがまったく可能であることを判断する必要があります。ムーアの法則はまだ有効であるため、悪いアルゴリズムでも10 年または 20 年で時間が短縮されることに注意してください。

最初にデザインを最適化します。たとえば、最初に動作させるようにします:-) 次に、パフォーマンスを最適化します。これは、Python プログラマーが本質的に行うトレードオフのようなものです。実行時は通常は遅いが、(C/C++ に比べて) 高レベルであり、したがって開発が高速な言語でプログラミングすることにより、python プログラマーはかなりのことを達成できます。次に、最適化に焦点を当てます。

1 つの注意点として、終了までの時間が長すぎて、アルゴリズムが正しいかどうかを判断できない場合は、上流の早い段階で最適化を検討するのに非常に適した時期です。私はこのシナリオに数回しか遭遇していませんが、知っておくとよいでしょう。

score 0 · Accepted Answer

データの増加を処理するコードの機能が心配な場合は、先に進む前に、サンプルデータセットを大きなチャンク単位でセットアップして、次のようにテストしてみます。

1000レコード
10000レコード
100000レコード
1000000レコード

どこで壊れたり、使用できなくなったりするかを確認します。次に、コアアルゴリズムを最適化または再設計する必要があるかどうかを、実際のデータに基づいて決定できます。

score 0 · Accepted Answer

運用シナリオについて考えます。(ユースケース)

ピザショップ検索ギズモを作っているとしましょう。

ユーザーがマシンの電源を入れます。有意義な時間内に最も近いピザ屋を彼に見せなければなりません。ユーザーは 15 秒以内にすばやく知りたいと考えていることがわかりました。

さて、あなたが考えているアイデアはどれでも、これは現実的に 15 秒未満の時間で実行され、他のすべての時間が重要なことに費やされることはなくなるのでしょうか..

または、あなたは取引システムです: 正確な合計。可能であれば、1 ミリ秒未満の取引でお願いします。(彼らはおそらく 10 ミリ秒を受け入れるでしょう)、したがって、agian: 関連するシナリオの観点からすべてのアイデアを検討します。

電話アプリだとしましょう: (何秒以内に) 開始する必要がありますか?

ラップトップから顧客へのデモンストレーションは、常にシナリオです。私たちはその製品を売らなければなりません。

誰かが物をアップグレードするメンテナンスは、常にシナリオです。

例として、ハードでAIを多用し、Lispでカスタマイズされたアプローチはすべて適切ではありません。または別のストロークでは、XML サーバー構成ファイルはユーザーフレンドリーではありません。

それがどのように役立つかを見てください。

score 0 · Accepted Answer

私に起こったことについて少し話をしますが、実際の答えではありません.

その一部がサーバー上で非常に大きなスキャン (画像) を処理しているクライアント用のプロジェクトを開発しています。私がそれを書いたとき、私は機能を探していましたが、コードを最適化するいくつかの方法を考えたので、より速く、より少ないメモリを使用しました.

今、問題が発生しました。このソフトウェアとベータテストのための潜在的なクライアントへのデモ中に、デモユニット (自己完結型のラップトップ) では、メモリの使用量が多すぎるために失敗します。また、非常に大きなファイルがある開発サーバーでも失敗します。

それは最適化でしたか、それとも既知の将来のバグでしたか. 今すぐ修正または最適化しますか? まあ、それは他の優先事項でもあるので決定されるべきです。

以前にコードを再最適化するために時間を費やしていたらよかったのにと思います。

optimization - 未知のもののために設計するときに最適化の危険を回避する方法は？

14 に答える 14

Related

Reference