イベントリスナーもテストループの反復ごとに追加および削除されるため、jsperfは、イベントのディスパッチと処理に関しては水を濁していると思います。ユースケースではイベントのディスパッチと処理の頻度が高いようですが、イベントハンドラーの追加と削除の要求は比較的低くなっています。
ネイティブイベントをカスタムイベントでラップすることに焦点を当てたjsperfをまとめてから、カスタムイベントを解除します。テストシナリオは以下に基づいています。
- カスタムイベントのリスナーの有無
- カスタムイベントに関連付けられたデータの即時初期化と遅延初期化
- 「軽い」対「重い」初期化の要求に対処する場合の上記の要因の影響
「重い」対「軽い」初期化要求をテストするために、各カスタムイベントは10または1000の乱数の配列を作成します。
カスタムイベントデータの遅延初期化について:
- リスナーがいるとき、怠惰な初期化イベントは通常少し遅くなりました。「軽い」データの場合、すぐに開始されるイベントの0.8倍の速度になることがありました。
- リスナーがない場合、遅延して初期化されたデータは通常、「軽い」データと「重い」データの両方で高速でした。「重い」データの場合、通常は2倍から10倍高速でした。
私の質問は、未聴取のイベントは迅速に処理されますか?
私が見たすべての中で、リッスンされていないイベントは、ハンドラーが関連付けられているイベントよりも常に高速に処理されます。しかし、これは、イベントハンドラー自体がかなり遅く、コストがかかる場合にのみ大きな影響を与えると思います。また、カスタムイベントの作成コストが高いほど、カスタムイベントがいずれかの方法で作成された場合に問題になることは少なくなります。
また、イベントがリッスンされていないことがわかっている場合、イベントを生成するための処理をスキップする方法はありますか?
2つのことが頭に浮かびます。
イベントがリッスンされているかどうかの知識を、イベントを生成してディスパッチするプロセスに公開し、リッスンしているものがないことがわかっている場合は、そのプロセスにイベントの作成をスキップさせます。
カスタムイベントを生成するコードは、ある時点でネイティブイベントをリッスンし、ネイティブイベントに基づいてカスタムイベントを作成するように聞こえます。このシナリオでは、カスタムイベントのイベントリスナーが追加されるまでネイティブイベントを無視し、カスタムイベントのすべてのリスナーが削除されたときにネイティブイベントを再度無視することができます。