12
コードの作成方法の段階的なシフトは、システムのパフォーマンスに影響しましたか？そして、私は気にする必要がありますか？
TD; DR： 私が尋ねていたものに関していくつかの混乱があったので、ここに質問の背後にある運転のアイデアがあります： 私はいつもそれが何であるかという質問を意図していました。当初はうまく表現できなかったかもしれません。しかし、意図は常に「モジュール式、分離、疎結合、分離、リファクタリングされたコード」であり、「モノリシックな単一ユニット、1か所ですべてを行う、1つのファイル、密結合された」コードよりも、それ自体の性質が著しく遅い。残りは単なる詳細であり、その際に私が出会った、または現在または将来出会うであろうさまざまな症状です。ある程度の規模では確かに遅いです。最適化されていないディスクのように、どこからでも断片を拾わなければなりません。遅いです。確かに。しかし、私は気にする必要がありますか？ そして問題は…ではない マイクロ最適化、時期尚早な最適化などに関するものではありません。「これまたはその部分を最適化して死ぬ」ことではありません。 それは何ですか？ それは、時間の経過とともに現れたコードの記述についての全体的な方法論と手法、および考え方に関するものです。 「このコードを依存関係としてクラスに挿入する」 「クラスごとに1つのファイルを書き込む」 「データベース、コントローラー、ドメインからビューを分離する」。 スパゲッティの均質な単一のコードブロックを書くのではなく、一緒に動作する多くの個別のモジュールコンポーネントを書く 現在-この10年以内に-ほとんどのフレームワークで見られ、主張され、規約で主張され、コミュニティを介して伝えられているコードの方法とスタイルについてです。「モノリシックブロック」から「マイクロサービス」への考え方の転換です。それに伴い、マシンレベルのパフォーマンスとオーバーヘッド、さらにプログラマレベルのオーバーヘッドの面で価格が発生します。 元の質問は次のとおりです。 コンピュータサイエンスの分野では、プログラミングに関しては思考の著しい変化に気付きました。私はこのようなアドバイスを頻繁に目にします。 より小さな関数ごとのコードを記述します（この方法によりテストと保守が容易になります） ほとんどのメソッド/関数の長さが数行になり、目的が明確になるまで、既存のコードをますます小さなコードチャンクにリファクタリングします（より大きなモノリシックブロックと比較して、より多くの関数を作成します） 1つのことだけを行う関数を書く-関心の分離など（通常、スタック上により多くの関数とフレームを作成します） より多くのファイルを作成します（ファイルごとに1つのクラス、MVC、ドメインアーキテクチャ、デザインパターン、オブジェクト指向などのレイヤーの目的のために、より多くのファイルシステム呼び出しを作成するために、分解の目的でより多くのクラス） これは、2500行にまたがるメソッドと、すべてを行う大きなクラスと神オブジェクトを持つ「古い」または「時代遅れの」または「スパゲッティ」コーディングプラクティスと比較した変更です。 私の質問はこれです： 呼び出しがマシンコード、1と0、アセンブリ命令、HDDプラッターに至るとき、リファクタリングされたさまざまな小から小の関数とメソッドを備えた完全にクラス分離されたOOコードも生成されることを心配する必要がありますか余分なオーバーヘッドですか？ 詳細 OOコードとそのメソッド呼び出しが最終的にASMでどのように処理されるか、またDB呼び出しとコンパイラー呼び出しがHDDプラッター上のアクチュエータアームの移動にどのように変換されるかについてはよく知りませんが、いくつかの考えがあります。追加の関数呼び出し、オブジェクト呼び出し、または（#include）呼び出し（一部の言語）は、追加の命令セットを生成するため、実際の「有用な」コードを追加することなく、コードの量を増やし、さまざまな「コードワイヤリング」オーバーヘッドを追加すると想定しています。また、ASMが実際にハードウェアで実行される前に、ASMに対して適切な最適化を実行できることも想像しますが、その最適化を実行できるのはそれだけです。 したがって、私の質問-十分に分離されたコード（何百ものファイル、クラス、デザインパターンなどに分割されるコード）が（スペースと速度で）どのくらいのオーバーヘッドをもたらすかは、「このオーバーヘッドのために、すべてを1つのモノリシックファイルに」 明確にするために更新： 同じコードを取得して分割し、リファクタリングし、より多くの関数とオブジェクト、メソッド、クラスに分離することで、より小さなコード間でより多くのパラメーターが渡されると想定しています。確かに、リファクタリングコードはスレッドを継続する必要があり、そのためにはパラメーターを渡す必要があります。より多くのメソッドまたはより多くのクラスまたはより多くのファクトリメソッドのデザインパターンは、単一のモノリシッククラスまたはメソッドの場合よりも、さまざまな情報を渡すオーバーヘッドを増やします。 どこか（TBDを引用）では、すべてのコードの最大70％がASMのMOV命令で構成され、実際の計算ではなくCPUレジスタに適切な変数をロードすると言われていました。私の場合、PUSH / POP命令を使用してCPUの時間を増やし、さまざまなコード間でリンケージとパラメーターの受け渡しを行います。コードを小さくするほど、より多くのオーバーヘッド「リンケージ」が必要になります。このリンケージがソフトウェアの肥大化とスローダウンに追加することを懸念しており、これを心配する必要があるのか、もしあれば、どれくらいの量を心配する必要があるのか、次の世紀のソフトウェアを構築しているプログラマーの現在と将来の世代、これらのプラクティスを使用して構築されたソフトウェアと共存し、使用する必要があります。 更新：複数のファイル 古いコードを徐々に置き換えている新しいコードを書いています。特に、古いクラスの1つが〜3000行のファイルであったことに注意しました（前述のとおり）。今では、テストファイルを含むさまざまなディレクトリに配置された15〜20のファイルのセットになりつつあり、いくつかのものを結合するために使用しているPHPフレームワークは含まれません。さらに多くのファイルが来ています。ディスクI / Oに関しては、複数のファイルのロードは、1つの大きなファイルのロードよりも遅くなります。もちろん、すべてのファイルがロードされるわけではなく、必要に応じてロードされ、ディスクキャッシングとメモリキャッシングのオプションが存在しますが、それでもメモリloading multiple filesよりも多くの処理が必要になると思いloading a single fileます。それを懸念に加えています。 更新：依存性のすべてを注入 しばらくしてこれに戻って..私の質問は誤解されたと思います。または、いくつかの答えを誤解することを選んだかもしれません。いくつかの答えが出てきたので、マイクロ最適化については話していません（少なくとも、マイクロ最適化について話していることは間違った呼び方だと思います）。 、コードのあらゆるレベルで。私は最近、このスタイルのコードがコンベンションの中心的なポイントの1つであり、Zend Conから来ました。ビューからロジック、モデルからビュー、データベースからモデルを分離し、可能であればデータベースからデータを分離します。依存関係-すべてを挿入します。これは、何もしない配線コード（関数、クラス、ボイラープレート）を追加することを意味する場合があります、ただし、シーム/フックポイントとして機能し、ほとんどの場合、コードサイズを簡単に2倍にします。 更新2：「コードをより多くのファイルに分割する」ことは、パフォーマンスに大きな影響を与えますか（コンピューティングのすべてのレベルで） compartmentalize your code into multiple files今日のコンピューティング（パフォーマンス、ディスク使用率、メモリ管理、CPU処理タスク）の哲学はどのように影響しますか？ …