GitHub複雑なウェブアプリケーションになってくると、1つのページで複数のTimerなどを回すことがあります。Twitterのようなアプリならば、ポーリングで更新するためにsetInvervalのようなタイマーを回します。ゲームなどCanvasで描画を行うアプリケーションならば、メインループをrequestAnimationFrameで回します。このように色々なタイマー系がありますが、アプリが多機能になっていくと色々なタイマーが同時に動くようになっていきます。問題がなりやすいのが表示中だけタイマーを回すコンポーネントです。あるのが次のようなmount時にtimerを開始して、unmount時にtimerを停止するコンポーネントです。この実装はunmount時に止めているので問題ありませんが、componentWillUnmountの実装を忘れるとそのタイマーはコンポーネントが消えた後も回り続けます。"requestAnimationFrame"の実行元の関数毎に呼ばれた回数をまとめて表示してくれます。スタックトレースも無理やり入れているので、意図しない呼び出しが頻発しているならその部分のコードを直す目安となります。twtter.comでこれを実行してみるとsetIntervalとrequestAnimationFrameが回っていることが分かります。これは定期的な更新をするために呼び出していることがわかります。タイムラインツールでも記録はできるのですが、呼び出し元毎のグルーピングやフィルタリングが難しいです。"requestAnimationFrame"を乗っ取ってログを取ることで実装しています。一回のタイマー発火ごとの処理は小さくても、スペック弱いデバイスではネックとなることがあるのでそのような無駄な処理を発見する目的で作りました。Throttlingなどでシミュレートすると問題を見つけやすいです)最近は、分かりやすい指標が既にある起動時間のパフォーマンスではなく、アプリを起動後のパフォーマンスを改善しています。次の記事で作ってたものはそういうところを改善する目安を探すためのツールです。Flux版を実装してたけど、やっぱりこういうの必要だと思う。ボトルネックが可視化されるので特殊な技能がなくてもパフォーマンス悪いところが発見できる。task)、Loadは1000ms以内などを指標を定めたRAILモデルなどがあります。これらはマイクロなベンチマークを取ってからそれを改善していくという積み重ねをしています。この記事で書いたspyスクリプトも、無駄に動くタイマーが減ればその分処理が減ったということが明確であるため、それを検出するために作りました。アプリ起動後は何もしてないときも体感が良いということも必要になります。ユーザー操作がないけど、タイムラインがスムーズに更新される、映像がスムーズに流れる、放置ゲームを眺めててつっかかりがないとか、リアルタイムにデータを受信してて止まらないなどがこれにあたります。"requestAnimationFrame"などを使っていることが多いです。(WebRTCやWebSocketなどもありますが、それらが止まってないかを定期的にチェックする仕組みなどにも関係します)タイマー系は意図しないタイミングで他の処理と重なるとUIを固めたりするので、requestIdleCallbackと組み合わせるなどの工夫が必要になるかもしれません。タグ:JavaScriptperformanceお知らせ欄JavaScriptに関する最新情報は週一でJSer.infoを更新しています。efcl/efcl.github.ioからご意見下さい関連記事コメントを。