Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

jsPerfで速度測定

More than 3 years have passed since last update.

コードの速度を測定するとなると、意外と準備とか評価が面倒ですが、JavaScriptの場合はjsPerfというサイトがあります。

使い方

まずは、GitHubアカウントが必要なので、連携ログインします。すると、入力フォームが出てきます。

  • Your details…作者の情報。なくても動きます。
  • Title…テストのタイトル(必須)
  • Slug…テストに振るURL(必須、既存のと重複不可)
  • Preparation code HTML…テスト用に準備しておくHTML。DOM操作のテストをする場合の準備や、あるいは<script>でJavaScriptライブラリを読み込んでおくなどに使えます。
  • Define setup for all tests…時間測定に入らない、事前準備の部分。必要な関数・変数を用意するなどに使いましょう。
  • Define teardown for all tests…時間測定に入らない、後片付けの部分。生成したDOM要素を処分するなど、必要な時があるかもしれません。
  • テストケース…比較対象を書いていきます。

これを入れれば、あとは「Run」を押すだけで、繰り返し測定、標準偏差の算出など、自動的に進んでいきます。同じURLにアクセスすれば、ブラウザを変えての測定もいとも簡単にできてしまいます。

注意点

「暗号の安全性確保のために処理速度がかかる必要がある、あるいは複数の処理対象で有意な時間差を作ってはいけない」というような例を除けば、「速くなることがデメリットになる」場面はほぼ存在しません。

ただし、速くしてどれだけのメリットがあるのかは、状況によって違ってきます。たとえば、ブラウザ上で行うイベント処理などは、速い方がいい…のは間違いないのですが、ブラウザが1フレームを描画し直す1/60秒に間に合うのであれば、それ以上高速化してもユーザーへのメリットはほぼありません。

ということで、自分の考える使い方は以下のようなところです。

  • 悪魔に魂を売ってでも、速さが必要な場合…思考ルーチンや仮想DOMのメインループなど、速さがプロダクトの価値そのものに直結する場合は、徹底的に考えて書く必要があります。
  • 関数などでラップできるような場合…関数化できる操作であれば、適切なテストを行いつつ、関数外には影響を及ぼさずに内部だけの最適化が可能です。
  • 地雷を避ける場合…JavaScriptでは、ときおり「書き方によって数十倍以上遅くなってしまう」ようなことがあります(実際に遭遇した例)。高速にチューニングする必要がないような場面でも、さすがに数十倍遅いものは選ばないほうがいいでしょう。

逆に、clickハンドラ内のコードを書くときに、「スコープの遠い変数が遅い」とか「i++++iは速度的にどっちがいいのか」なんてのを気にするのは、やりすぎです。

jkr_2255
qiitadon
Qiitadon(β)から生まれた Qiita ユーザー・コミュニティです。
https://qiitadon.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away