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処理タスク)の哲学はどのように影響しますか?
私は話している
前...
それほど遠くない過去の非常に現実的な仮説では、モデルとビューおよびコントローラーのスパゲッティまたは非スパゲッティコーディングされたファイルの1つのモノブロックを簡単に記述できますが、既にロードされるとすべてを実行します。過去にCコードを使用していくつかのベンチマークを行ったところ、1つの900Mbファイルをメモリにロードして大きなチャンクで処理する方が、多数の小さなファイルをロードして小さなピースミールで処理するよりもはるかに高速であることがわかりました最終的に同じ作業を行うチャンク。
.. そしていま*
今日、私は元帳を表示するコードを見ていることに気付きました。これは、..アイテムが「注文」の場合、注文のHTMLブロックを表示するなどの機能を備えています。広告申込情報をコピーできる場合は、その背後にアイコンとHTMLパラメータを表示するHTMLブロックを印刷して、コピーを作成できるようにします。アイテムを上下に移動できる場合は、適切なHTML矢印を表示します。など、Zend Frameworkで作成できますpartial()
これは、本質的には「パラメータを取得し、それも呼び出す別のHTMLファイルに挿入する関数を呼び出す」ことを意味します。取得する詳細度に応じて、元帳の最も小さな部分に対して個別のHTML関数を作成できます。1つは上向き矢印、下向き矢印、「このアイテムをコピーできます」などです。Webページの小さな部分を表示するためだけに複数のファイルを簡単に作成できます。私のコードと舞台裏のZend Frameworkコードを取り上げると、システム/スタックはおそらく20〜30近くの異なるファイルを呼び出します。
何?
私は、コードを多くの小さな個別のファイルに区分化することによって作成されるマシンの損耗などの側面に興味があります。
たとえば、より多くのファイルをロードするということは、ファイルシステムのさまざまな場所、および物理HDDのさまざまな場所にそれらを配置することを意味し、より多くのHDDシークおよび読み取り時間を意味します。
CPUの場合は、おそらくコンテキストの切り替えとさまざまなレジスタのロードが増えることを意味します。
このサブブロック(更新#2)では、複数のファイルを使用して、単一のファイルで実行できる同じタスクを実行し、システムのパフォーマンスにどのように影響するかに、より厳密に興味があります。
Zend Form APIと単純なHTMLの使用
Zend Form APIを最新かつ最高の最新OOプラクティスとともに使用して、検証付きのHTMLフォームを構築し、POST
ドメインオブジェクトに変換しました。
35個のファイルを作成しました。
35 files =
= 10 fieldsets x {programmatic fieldset + fieldset manager + view template}
+ a few supporting files
これらはすべて、いくつかの単純なHTML + PHP + JS + CSSファイル(おそらく合計4つの軽量ファイル)で置き換えることができます。
良いですか?それは価値がある?... 35個のファイルと、それらを機能させる多数のZend Zrameworkライブラリファイルをロードすることを想像してください。