速すぎることのデメリット

今日、いくつかの変更を追跡していたときに、このコミットコメントを見つけました。

The bugfix for COM-xxxx seems to make the importing
of metafields too fast and causing too many events raised,
potentially flood the event system. This avoids raising the events
unnecessarily.

これを書いたのは誰ですか? 私、5年近く前のことです。 若い頃の自分は残酷なまでに正直だったので、私は頭の中でくすくすと笑いました（最初のバグを修正したのは私だったので、それを「速すぎた」のは私の責任でした）。 短期間にあまりに多くのイベントを送信したため、イベント システムが過剰になり、他の一部のイベント (他の部分のキャッシュの無効化など) が処理されませんでした。

バグ修正により、発生するイベントの数が減り、さらに高速化されました。 最後にはみんな幸せでした。

この話の教訓：

• システムは最も遅いコンポーネントと同じ速度しか実現できません。 努力するときはそのことを念頭に置いてください。 ほとんどの場合、最も遅い部分に時間を費やす必要があります。
• 最適化がエンドツーエンドであることを検証することが重要です。 他の部分 (その部分) がこの部分に追いつけなかった場合に、予想外に速くなった場合、速ければ速いほど良いとは限りません。
• すべてを予測することはできません。何かが最も予期せぬ形で起こることもあります。 素早く行動し、物事を破壊し、そこから学び、修正してください。 洗い流して繰り返します。