大きくて複雑なソフトウェア製品を遅くするものは何ですか？[閉まっている]

あまり関係のない理由で、私はDelphi 7をこのような長い時間でもう一度インストールしました。私は言わなければならない、私は完全に吹き飛ばされた-私はかなりしばらくの間ではなかった方法で。これは私が物事を覚えている方法ではありません。インストールには約30秒かかりました。起動には2秒かかり、すぐに使用できました。開始後、2番目に「実行」を押すと、1秒以内に空のプログラムが既に表示され、実行されています。コンピューターの速度が大幅に向上しました！

しかし、私がこのように吹き飛ばされた理由は、通常私はVisual Studio 2010を使用しているためです。確かに、デルファイ7は、Visual Studio 2010よりもはるかに小さいシステムであるが、それは持っている外観がすべて本当に必要なものを持っていることの：コントロールパレット、フォームデザイナ、コード補完とコードエディタを。言語がよりシンプルで、コード補完のパワフルさが少なく、IDEの拡張性や機能が豊富ではないかもしれないことを理解していますが、それでも：（どのメカニズムを介して）どのように機能するのかわかりません多くの追加機能（まだトリガーしていなかったかもしれません）により、Visual Studioのようなシステムは常に比較して低迷します。

システムの操作に経験のある人にVisual Studioの規模を聞いてみたいと思います。それが遅くなる原因は何ですか？コードベースを人間の理解能力の範囲内に保つために必要な抽象化のレイヤー上のレイヤーですか？実行する必要があるコードの量は膨大ですか？それは、クロックサイクル/メモリ使用部門の（驚くほど巨大な）費用で、プログラマの時間節約アプローチに向かう現代の傾向ですか？

建築天文学

Visual Studio 2010は、Windows Presentation Foundation上に構築されています。WPF のButtonクラスを見てください。基本クラスの9番目の子です。約5ページのプロパティ、メソッド、イベントがあります。舞台裏には、さらに5ページのスタイル定義があり、美しく丸い角と、マウスカーソルが上に移動したときの微妙なアニメーションの遷移を記述しています。これは、基本的にテキストまたは画像を表示し、マウスボタンのダウンを検出するとクリックイベントを生成するもののためのものです。

任意の時点でVisual Studioなどのプログラムを停止します。スタックトレースを見てください。呼び出しスタックの20レベルの深さであり、そこに到達するために5つのDLLがロードされたことは非常に良いことです。

次に、これら2つのことをDelphiと比較します。Delphi Buttonには、20のプロパティ、メソッド、およびイベントしかありません。Delphi IDEには、5〜7レベルのスタックトレースしかありません。コンピューターの速度が遅い場合、IDEの起動に40分かかることなく、Visual Studio 2010のオーバーヘッドを取ることができなかったからです:-)

一方が他方より優れていますか？まあ、それは平らに見え、色がミュートされているため（おそらく8ビット？）、微妙なシェーディングやアニメーションがないため、一般的にDelphiプログラムにロードするときに伝えることができます。私は最近「安い」と感じています。安いが、速い。

私たちは良いですか？これは、コーダーではなく哲学者にとっての質問です。

システムの操作に経験のある人にVisual Studioの規模を聞いてみたいと思います。それが遅くなる原因は何ですか？コードベースを人間の理解能力の範囲内に保つために必要な抽象化のレイヤー上のレイヤーですか？実行する必要があるコードの量は膨大ですか？それは、クロックサイクル/メモリ使用部門の（驚くほど巨大な）費用で、プログラマの時間節約アプローチに向かう現代の傾向ですか？

あなたはそれらの多くを推測したと思いますが、私は最大の要因であると考えるものを提供しますカテゴリおよび約1,000のプラグイン）約10年間、観測現象が発生します。

また、APIや言語機能などに移行しないため、少し物議をかもします。それらは、「支出」ではなく議論を生むことができる「費用」に関連しており、「支出」に焦点を当てたいと思います。

緩い調整とレガシー

私が観察したのは、調整が緩く、長い遺産が多くの無駄を蓄積する傾向があるということです。

たとえば、このコードベースには約100個の加速構造があり、それらの多くは冗長です。

ある物理エンジンを加速するためのKDツリー、古い物理エンジンと並行して実行されることが多い新しい物理エンジン用のKDツリー、さまざまなメッシュアルゴリズム用のoctreeの実装、レンダリング用の別のKDツリーが必要です。 、ピッキングなどなど。これらはすべて、検索を高速化するために使用される大きくてかさばるツリー構造です。非常に平均的なサイズの入力では、それぞれが数百メガバイトからギガバイトのメモリを消費する可能性があります。それらは常にインスタンス化されて常に使用されているわけではありませんが、いつでも4つまたは5つが同時にメモリ内にある可能性があります。

今では、これらすべてがまったく同じデータを保存して、それらの検索を高速化しています。すべてのフィールドを20の異なる冗長マップ/辞書/ B +ツリーに一度に格納し、同じキーで同じように整理し、すべてを常に検索する類推的な古いデータベースのように想像できます。現在、20倍のメモリと処理を使用しています。

さらに、冗長性のため、それらに付属するメンテナンス価格タグでそれらのいずれかを最適化する時間はほとんどありません。最適化しても、理想的な効果の5％しかありません。

この現象の原因は何ですか？緩い調整が私が見た最大の原因でした。多くのチームメンバーは、孤立したエコシステムで作業し、サードパーティのデータ構造を開発または使用していますが、まったく同じ懸念事項のあからさまな重複であっても、他のチームメンバーが使用している同じ構造を使用していません。

この現象が持続する原因は何ですか？レガシーと互換性は私が見た最大の原因でした。これらのデータ構造を実装するためのコストをすでに支払っていて、大量のコードがこれらのソリューションに依存していたため、それらをより少ないデータ構造に統合しようとすることは非常に危険です。これらのデータ構造の多くは概念的に非常に冗長でしたが、それらはインターフェース設計において常に同一に近いとは限りませんでした。したがって、メモリと処理時間を消費させるだけではなく、それらを置き換えることは大きなリスクのある変更でした。

メモリ効率

通常、メモリ使用量と速度は、少なくともバルクレベルで関連する傾向があります。多くの場合、メモリの占有率によって、遅いソフトウェアを見つけることができます。そうではありません、常にすべてのプログラムがメモリの最大積載量を使用している場合は、それの唯一の1メガバイトが使用されている-どのような重要なの「ホット」メモリ（何メモリはすべての時間をアクセスされているであることから、景気減速へのより多くのメモリリードというのは本当時間、それはそれはそれほど速度ではない大したことではありません）。

そのため、多くの場合、メモリ使用量に基づいて潜在的な豚を見つけることができます。アプリケーションの起動時に数十から数百メガバイトのメモリを使用する場合、おそらく非常に効率的ではありません。最近ギガバイトのDRAMを使用している場合、数十メガバイトは小さいように見えますが、最大で最も遅いCPUキャッシュは依然としてわずかなメガバイトの範囲であり、最速はまだキロバイトの範囲です。その結果、20メガバイトを使用して起動するだけで何もしないプログラムは、特に20メガバイトすべてのメモリが繰り返しアクセスされる場合、実際にはハードウェアCPUキャッシュの観点からかなり多くのメモリを使用しています。プログラムの実行中に頻繁に。

解決

私にとっての解決策は、より調整された小さなチームを探して製品を構築することです。彼らは、「支出」を追跡し、同じアイテムを何度も「購入」することを避けることができます。

費用

私が観察した「支出」現象については、少し物議を醸す「コスト」の側面に少し触れます。言語が、オブジェクトの避けられない価格タグ（ランタイムリフレクションを提供し、一連のオブジェクトの連続的な割り当てを強制できないもの）で終わる場合、その価格タグは、非常に粒度の高い要素のコンテキストでのみ高価ですシングルPixelまたはBoolean。

しかし、このようなきめ細かいレベルでそのコストを払う重い負荷（例：数十万から数百万PixelまたはBooleanインスタンスを処理する）を処理するプログラムの多くのソースコードを見ています。

オブジェクト指向プログラミングは、それをさらに悪化させる可能性があります。しかし、それは「オブジェクト」自体のコストではなく、障害のあるOOPでさえありません。そのようなコストは、数百万単位でインスタンス化されるような細かい要素のレベルで支払われているだけです。

それが、私が観察している他の「コスト」と「支出」の現象です。費用は1ペンスですが、大量購入のためにメーカーと交渉するのではなく、100万缶のソーダを個別に購入する場合は、ペニーが加算されます。

ここでの解決策は、「一括」購入です。このコストがソーダ缶の類推に相当する数百万回以上個別に支払われていない限り、オブジェクトはそれぞれに少額の価格がある言語でも完全に問題ありません。

時期尚早の最適化

ここで使用されているKnuthの文言があまり好きではありませんでした。「時期尚早な最適化」により、実際の生産プログラムが速くなることはめったにないからです。Knuthが「適切な知識/経験なしで最適化してソフトウェアへの真の影響を知る」ことを意味する場合、「早期に最適化する」と解釈する人もいます。何かが、真の時期尚早な最適化の実用的な効果は、多くの場合、ソフトウェアを作るつもりされている場合は遅くなり、メンテナンス性の手段で劣化するのでクリティカルパスの最適化には少し時間があります、本当に問題が。

これは私が観察した最後の現象です。開発者は、1缶のソーダの購入でペニーを節約し、再び購入することはできません。さらに悪いことに、家は、ペニー（または、さらに悪いことに、他の場所で無駄に数十億ドルが費やされたときに、コンパイラーまたはハードウェアのアーキテクチャーを理解できなかった）。

時間は非常に限られているため、適切なコンテキスト情報を持たずに絶対値を最適化しようとすると、真に重要な場所を最適化する機会が奪われることがあります。したがって、実用的な効果という点では、 」

問題は、オブジェクトについて上記で書いたことを取り上げ、オブジェクト指向プログラミングやそのようなクレイジーなものを禁止するコーディング標準を確立しようとする開発者タイプがあることです。効果的な最適化は効果的な優先順位付けであり、メンテナンスの問題の海にdrれている場合は絶対に価値がありません。