「コードの最適化」==「データの構造化」はいつですか？

ycombinatorによる最近の記事に、優れたプログラマーの原則を伴うコメントがリストされています。

#7.良いプログラマー：コードを最適化します。優れたプログラマー：データを構造化します。最高のプログラマー：違いは何ですか？

主観的で論争のある概念を認める-これが何を意味するかについて誰かが立場を持っていますか？私はそうしますが、私は後でこの質問を自分の考えで編集して、回答の素因を作らないようにしたいと思います。

10回のうち9回、コード/モデルを適切に構造化すると、最適化が明らかになります。スズメバチの巣を何回目に見て、それが完全に最適ではないことに気づきましたか？それを再構築すると、多くの冗長性が非常に明白になりました。

デザイナーは、追加するものが残っていないときではなく、取り除くものが残っていないときに完璧を達成したことを知っています。 -アントワーヌドサンテグジュペリ

十分に構造化されたシステムは本質的に最小限であり、その最小限の性質のために最適化されます。それは、それがどれほど少ないかが、その目標を達成するためにどれだけ少ないかに直接関係するためです。

編集：他の人がこれから取り除いた点を説明するために、コードとデータの間の関係を識別するものとしてステートメントを見るのも完全に正確です。したがって、その関係は次のとおりです。データの構造を変更する場合、変更された構造を尊重するようにコードを変更する必要があります。コードを最適化したい場合は、データの構造を変更して、コードがデータをより最適に処理できるようにする必要がある可能性があります。

とは言っても、ここで回避できた可能性はまったく別のものであり、YCombinatorとの関係を持つこのフェローは、LISPの同型性の伝統におけるコードASデータを参照している可能性があります。これを私の心の中での意味だと推測するのは一続きですが、それはYCombinatorであるため、LISPerが「最高のプログラマー」であると単に引用しているだけであることを否定しません。

著者は、データの再構築はコードの再構築につながることをほのめかしていると思います。したがって、システムを最適化する目的でデータを再構築すると、コードも最適化され、「違いは何ですか？」応答。

「優れたプログラマ」が「違いは何ですか？」と答えることがあることに注意してください。CPUキャッシュの使用を改善するために最適化に取り掛かると、データ構造のレイアウトを同じに保つことができますが、それらにアクセスする順序を変更すると、多くのことができるようになります。差。

この最も明白な例を考えてみましょう-「ユーザーデータの検索が遅すぎます！」

ユーザーデータにインデックスが付けられていないか、少なくとも並べ替えられていない場合、データを再構築すると、すぐにコードのパフォーマンスが向上します。データが適切に構造化されていて、（インデックスを使用したり、バイナリ検索のようなものを実行したりするのではなく）コレクション全体を反復している場合、コードを変更するとコードのパフォーマンスが向上します。

プログラマーは問題解決者です。アルゴリズムとデータ構造を区別することは有用ですが、それらを分離して存在させることはできません。最高のプログラマーはこれを知っており、不必要に自分自身を分離しないでください。

私は上記の声明に同意しませんが、少なくとも説明はありません。コーディングは、いくつかのデータ構造の利用を伴う活動だと思います。データ構造は一般にコーディングに影響を与えます。だから私の意見では両者には違いがあります。

著者は最後の部分を「最高のプログラマー：私は両方を最適化する」と書いたはずだと思います。

Algorithms + Data Structures = Programsと呼ばれる素晴らしい本があります（少なくとも出版されたときはそれがありました）。

コードを最適化すると、速度が2倍、時には10倍、場合によっては20倍も速度が向上することがありますが、それだけです。それは多くのように聞こえるかもしれません、そして、プログラムの実行時間の75％が速度が簡単に2倍にされるかもしれない5行のルーチンで費やされるなら、そのような最適化は作る価値があるかもしれません。一方、データ構造の選択は、実行速度に何桁もの影響を与える可能性があります。非常に最適化されたコードを実行して、RAMに格納された10,000,000アイテムの線形リンクリストのキーでデータを検索する最新のハイパー最適化マルチスレッドプロセッサは、単純にコード化されたネストされたハッシュテーブルを実行するはるかに遅いプロセッサよりも遅くなります。実際、データが適切にレイアウトされていれば、1980

そうは言っても、効率的なデータ構造を設計するには、コードを最適化するよりも複雑なトレードオフが必要になることがよくあります。たとえば、多くの場合、データへの最も効率的なアクセスを可能にするデータ構造は、高速の更新を可能にするものよりも（場合によっては桁違いで）更新の効率が低く、最も速い更新を可能にするものは、最も遅いアクセスを可能にする可能性があります。さらに、多くの場合、大きなデータセットに最適なデータ構造は、小さなデータセットでは比較的非効率的です。優れたプログラマーは、さまざまなデータ構造を実装および維持するために必要なプログラマーの時間とこれらの競合する要因のバランスを取り、それらの間で適切なバランスを取ることができるように努力する必要があります。

データ構造は、パフォーマンスに関連して多くのことを推進します。理想的なデータ構造についての先入観を持って問題を一生懸命見つめることができると思います。このような考えの中で、最適化の証明（多くの場合、帰納法）さえ作成します。たとえば、並べ替えられたリストを配列に入れ、要素を挿入するためのコストなどを評価する場合、平均して、挿入ごとに配列の1/2をシフトする必要があると判断します。バイナリ検索ごとに、log nステップで一致するアイテムを検索できます（または検索できません）。

または、データ構造に関する決定を先延ばし（時期尚早な最適化を避けます）、入ってくるデータとそれを使用するコンテキスト、データの大きさ、発生するレイテンシ、ユーザーにとって重要なもの、メモリの量を調べます対は、私たちが知っている、または考案できるデータ表現で使用します。

並べ替えや検索などの分野では、知っておくべきことがたくさんあります。本当に素晴らしいプログラマーが長い間これに取り組んできました。これらの問題をよく理解することは有用であり、学部生のデータ構造クラスを終了したときよりも多くのメソッドを知っていることは素晴らしいことです。 バイナリツリーは、メモリ使用量を増やす代わりに、挿入に対して優れたパフォーマンスを提供できます。 ハッシュテーブルはさらに大きな改善を提供しますが、より多くのメモリを提供します。基数ツリーと基数ソートは、さらに改善をもたらすことができます。

データの創造的な構造化は、問題を再構成し、ハードアプリケーションを高速化し、時には不可能なタスクを可能にする新しいアルゴリズムへの扉を開くのに役立ちます。

どのような記事手段で私の最高の推測を明確にするために、私はあること（記事に欠けていると思われる）暗黙の言外の意味を仮定します任意のプログラマが最適化について理解する必要があります。

• 最適化は、プログラムを起動して正しく実行した後でのみ行われます。
  • それが正しく実行させる、そしてそれが高速に実行させます
  • この原則はKnuthの格言の要点であり、「時期尚早な最適化はすべての悪の根源です」
• 最適化が時期尚早ではないと判断した場合は、まずそれを適切に測定して、実際に最適化が必要なものを判断し、最適化中に何度も繰り返して、最適化の試行がどのような影響を与えているかを知る必要があります。
  • コードが開発で実行されている場合、プロファイラーはこれの友です。
  • コードが本番環境で実行される場合は、コードをインストルメント化し、代わりにロギングシステムと友達にする必要があります。

さて、次に：測定値は、コードのどこでマシンが最も多くのサイクルを燃焼しているかを示します。「良い」プログラマーは、関係のない部分を最適化する時間を無駄にするのではなく、コードのそれらの部分を最適化することに焦点を当てます。

ただし、多くの場合、システム全体を見て、マシンの処理量を減らす方法を見つけることで、より大きな利益を得ることができます。多くの場合、これらの変更はデータの編成をやり直す必要があります。したがって、「より優れた」プログラマーは、データを構造化する頻度が高くなります。

「最高のプログラマー」は、マシンがどのように機能するかについての完全なメンタルモデル、アルゴリズム設計の十分な基礎、およびそれらがどのように相互作用するかについての実際的な理解を持っています。これにより、システム全体を統合したものと見なすことができます。コードとデータの最適化に違いはなく、それらをアーキテクチャレベルで評価するためです。

最高のプログラマー：違いは何ですか？

最高のプログラマー？いいえ。ルーシープログラマー。「最適化」という言葉は、プログラマが通常メモリやCPU時間を最適化しようとすることを意味していると思います。この意味で、最適化は他のほとんどすべてのソフトウェアメトリックの粒度に反します。理解しやすさ、保守性、テスト容易性など：最適化が目標である場合、これらはすべて人間の理解しやすさ、保守容易性、テスト容易性などを除いて、最適化を試みている場合を除き、すべて簡単に行うことができます。コストは言うまでもありません。速度/スペース最適化アルゴリズムを作成すると、テキストやジャーナルで提示されているようにアルゴリズムを単純にコーディングするよりも、開発者の時間の点でかなり多くのコストがかかります。お粗末なプログラマは違いを知りません。良いものはそうします。最高のプログラマーは、何を最適化する必要があるかを正確に判断する方法を知っており、それを慎重に行っています。