Kirk Pepperdine氏が新たな記事でJavaScriptのパフォーマンス性の詳細に迫っている。彼の一番最初の見解はJavaScriptエンジン仕様がJVMのものよりも遥かに弱いということだ。それぞれが異なる実行プロファイルを持った多大な数のJavaScriptインプリメンテーションが存在する。そのキーポイントをよそに彼は下記のトピックに関するJavaScriptを更に深く掘り下げている。
ゲッター/セッター
・・・最も不快度が高いと思われるアドバイスは聞いたらJavaの世界から立ち去りたくようなものなのです。まず初めにそのアドバイスはメソッド コールのオーバーヘッドを防ぐために直接的なアクセスに興じてゲッターやセッターを使うのは避けたほうが良いということです。
キャッシングによる悪質マイクロベンチマーク
JavaScriptエンジン内ではダイナミックな最適化があまり行われていないのでマイクロベンチマークがJavaで実行するよりもかなり簡単と思うかもしれません。 問題は異なるがJavaScriptの マイクロベンチマークもそう簡単なものではありません。一番多い悪質のマイクロベンチマークの要因はキャッシングです。キャッシングでウェブが生きるか死 ぬかの世界なのです。そしてキャッシングは至るところで使われています。またそれ以上にそれはよく隠されているものなのです。メモリリーク
最も興味深かった調査はメモリリークとメモリプロファイリングに関する良いブログエントリーの欠如だったのです。・・・私が持っていた大きな疑問はブラウザ内でJavaScriptからどのようにメモリリークが発生するのかということです。これには二つのオプションがあります。まず一つ目はDOMに隠されているたくさんの要素を保持することです。そしてもっと興味深くて見つかりにくいメモリリークはクロージャの使用から来るのです。
CPU Load
最後に、クライアントパフォーマンスに関する問題についてのブログはあまりありませんでしたが、そんなにたくさんのJavaScriptアプリケーションには確答しないように見えます。すなわちJavaScriptの広い範囲での仕様がCPUを蝕む傾向にあるのです。・・・JavaScriptは酷使しようとするとクライアントマシーンがCPUの制約に遭遇します。
Pepperdine氏は、Yahooによって定義されたJavaScriptのパフォーマンス問題をチェックする、YahooのYSlow Firebugベースのパフォーマンスツールに関する文にて議論を締めくくっている。最近発表されたJavaScriptを搭載したパフォーマンスフロント用のツールはJavaScript実行のjProfileスタイルパフォーマンス比較を許容するJsLexである。またマイクロソフトリサーチはAjax Viewというプロファイリングプロキシ技術の開発を進めている。