プラシーボ効果はもちろんご存知ですよね?
id:ofk さんの記事 http://d.hatena.ne.jp/ofk/20080912/1221205218 に書かれている「結論」に妖気を感じたので、釣られてやってみた。
内容は
- == の次に === で比較するものをTEST1
- === の次に == を比較するものをTEST2としています。
ofkさんの試した環境(IE7 と Firefox3)では、都合により試していません。
スクリーンショットは、IE6, Safari3.1, Opera9.6β, Google Chromeβです。
その前に「テスト」ってなんだっけ?
- アトミック性: テストの順番を変えるだけで結果が変わるようなテストは、テストではない。
- 収束性: テストの度に大きく(今回は10%以上)結果が変わるようなテストは、テストではない。ノイズである。
- 再現性: 再現性の低いテストはテストではない。再現が難しいテストは良いテストではない。
こういうのが大事かと。
IE6 で TEST1(==を先に評価)
| == | === | |
| 266 | 282 | 先にテストした==が早い |
| 156 | 156 | 同じ |
IE6 で TEST2(===を先に評価)
| === | == | |
| 234 | 266 | 先にテストした===が早い |
| 172 | 156 | 後からテストした==が早い |
私の環境での結果(結論ではない)
ofk さんが IE にフォーカスしているようなので IE6 のスコアを載せました。
IE6 はテストする順番で結果が大きく変化しました。
私が知るブラウザの多くは、Job投入後は一定期間(特定のリフレッシュ動作や時間)を置いてから別のJobを投入しないと結果が安定しないようです。IE6 もその部類です。特にページ表示直後などは安定した動作は望めません。
ただ、JITを搭載したV8(Google Chrome)では、10回中7回は === が早いという結果がでました(サンプル数は200)。
文字列を new String() したもので試すとか、ループを使わずに a === "b"; を死ぬほどべた書きしてみるとかすると、もっと結果が収束するかもしれません。
ひとりごと
※ 以下は、私の立ち位置からの視点で述べています。立ち位置が違う人からは違う思惑で受け止められるでしょうが、それも含めてありだと思います。
私は、数年後の世界にあわせた設計を施したいので、現時点でトップクラスのエンジン(V8, Gecko, WebKit)に合わせた設計を行っています。
「志は上を目指し、民衆は低きに流れる」ではありませんが、そういう意味では(== vs ===)の真意を伝えきれなかった私が悪いのかもしれません。
私は、IE ではハッキリとした決着が出ない気がしますし、たとえ決着がでても V8やGeckoで遅くなるように改悪することもありません。
V8はMSに対するGoogleからの挑戦状で「これが次世代のスタンダードだ、お前らにできるのか?」というメッセージが含まれていると感じます。
IE 開発者はやる気がないんだから IE が遅いのは当たり前です。やる気が無い人に合わせるとこっちまでやる気が無くなります。
この2〜3日はIEのバグのおかげでやる気がフッ飛んでしまって、なんか頭の中がぐるぐるしている最中なので、そう感じているのかもしれません、
読まれる方には申し訳ないのですが、ちょっと毒を吐いてみました。
IEで遅くても私はかまいません。IEで遅いのはIEが遅いからです。
IEユーザというものは他のブラウザと比較する機会を放棄しているため「遅い」という事実すら認識できません。現状に満足している人というのは、別の何かを探さないものです。
