私は最適化に精通しています。私は他の人のプログラムを別の目で見ています-これが私の見解です：
通常、マイクロ最適化は次の説明では価値がないと見なされます。プログラムを1パーセント未満高速化する可能性がありますが、その小さなブーストを気にする人はいません。
面白いのは、そのような変更の1つが99％につながることです。このような10の変更により、プログラムが著しく高速になります。多くのエンジニアにとって、プログラムの記述方法を変更すると、プログラムの実行が数倍速くなる場合があります。効率性を認識し、そのように書くだけで、追加の作業をせずにプログラムを数倍速くすることができます。そのような利益は、マイクロ最適化ではありません、imo。
注：このディスカッションでは、状況に応じて隅々まで最適化を提案することはありません。
さらに、1秒間に1000回起動し、非常に高速に終了するイベントハンドラが存在する可能性があります。それがどれほど速いかは誰も気にしません-それがすでに「観察できるほど速い」ので、それを速くすることは注目に値しません。
また、1kHzは多くの場合に必要とされるよりもはるかに高いため、すでに必要以上の作業を行っている可能性があります。このイベントハンドラーのソースは何で、その効果は何ですか。それが単にUIを更新していて、イベントが収集されて合体する可能性がある場合、1kHzのディスパッチは確かに過剰です（1％よりはるかに多く、25倍以上）。複数のソースを持ち、シリアルで送信されるシステムの場合、1kHzは十分に速くない場合があります（例：MIDI）。
ただし、モバイルデバイスではエネルギー消費が重要な要素です。同じイベントハンドラーを10％速く実行するように最適化すると、消費されるエネルギーが少なくなり、バッテリー寿命が長くなり、デバイスの動作時間が長くなります。モバイルデバイスに関する後者の判断はどの程度正確ですか？それを確認または反証する実際の例はありますか？
私が見たプログラムに基づいて、プログラムを書くためのあなたのアプローチを変えることが信じられないほどの利益を生み出すことができても（> 10倍以上）、そのような最適化を検討（または懸念）する人はそれほど多くありません。（アプリ開発側で）私が見た多くは、書き込みを行ってから、パフォーマンスの問題が追いついたら（/ ifの場合）トップダウンまたは「メアリー」アプローチを採用します。同様に、多くの人はそのような事態が発生するまで時間をかけてプロファイルを作成することすらしません。そのときまでに、非常に多くの複合的な非効率性のノイズにより、プロファイラーから有用な情報を取得することが非常に困難になります。ヘイルメアリーアプローチの例は、間違った領域を最適化する（問題領域を探すかどうかにかかわらず）、または問題領域にさらにコアを投げるだけです。これは、既存の非効率性を修正するのではなく行われます。
（私が見たモバイルプログラムの中で）典型的な既存のプログラムの場合、最適化はそれが書かれたときに大きな問題ではありませんでした。したがって、予算内であり、優先度が高い場合は、「はい」の場合（通常の場合）は時間の価値があります。その場合、プログラムを著しく高速にするこれらの10の変更は、数時間で1日未満で実行できる可能性があります。
プログラムを改善するための唯一のアクションはひどい考えなので、「遅延してプロファイルを振り返って書く」というのはひどい考えです。効率的なプログラムの記述方法を（時間をかけて、最後に一緒にテーピングするのではなく）書くことは優れています。アプローチ（imo）; 適切なアルゴリズムを使用し、無駄なコピー、割り当て、計算を禁止します（+多く、他の多くのカテゴリ）。もちろん、レトロスペクティブでパフォーマンスを分析することにはメリットがありますが、プログラムを最初から効率的に書くと、多くのことを学び、複数の観点から実行を検討および評価するため、まったく新しいレベルの効率になります。
もう1つは、プログラムは（多くの場合）再利用のために作成する必要があることです。不十分に作成されたプログラムは、非効率性が取り除かれたときにクライアントのプログラムを破壊する可能性のある変更を導入します（または既存のプログラムの破壊を避けるために非効率なままです）。
書くときにそれを考慮することの1つの大きな利点は、プログラムがどのように動作するかを完全に理解していることです（完全な図ではありません）。この情報を使用して、インターフェースの設計とデータの格納方法を支援できます。 。真実は、エンジニアは、OSで提供される標準の「1つのサイズですべてに適合する」ソリューションよりも数倍（たとえば> 10倍）速いものを実装できることです。
最後に、モバイルデバイスを超えた価値もあります。ハードウェアは2年間で速くなるという考えで書かれた非効率的なプログラムが世の中にたくさんあります（今日書かれたプログラムであっても、根拠は頻繁です！）。それは不正確ではありませんが、楽観的すぎます。同様に、並列化には目的がありますが、それは多くのプログラムにとって間違った「デフォルトの解決策」です。これらの既存のプログラムの多くは、最初に既存の非効率性を取り除くことで最も改善できます。
ですから...現実の世界では、通常、1％、2％、7％（およびさらに悪い）のケースが大量にあります。それらを修正するか、または（より重要なことに）そもそもそれらを記述/公開しないことは、大きな利点を提供できます。これらのケースの多くは簡単に特定して修正できます（エンジニアがこれにある程度の経験がある場合）。しかし、事実を修正して再テストするのは本当に大変です。プログラムが最適化されている場合、理想的には最初からそのように記述されます。
エンドユーザーとして、低速のプログラムを継続的に待機し、低速/非効率的なプログラムによって発生する問題に対して2倍のハードウェアを投入するのはイライラします。A：「ソフトウェアをアップグレードする前の応答性と生産性を取り戻す-それだけです。」開発者（imho）をまったく考慮していません。