アカウント名:
パスワード:
JavaScriptでミリ秒単位の実行速度なんて開発者の自己満足だろ・・・。
決して開発者の自己満足ではないと思います。自分の考えでは、今までが遅すぎたのであって、今の速度競争は決して速度偏重に陥っているとは思いません。自分も過去のブラウザ乗り換え履歴を思い返してきたのですが、ネスケ4に機能不足を感じつつも使っていたのはIE4の起動が遅すぎたからでしたし、逆にIE5で起動が高速化されてからはネスケを起動することはなくなりました。Operaも「世界一高速」を謳っていたころに一時期使っていましたし、今から思えば、DountLに乗り換えた時も最初の頃はタブブラウザよりも起動の軽さに魅力を感じていました。同じことはFi
なんか盛り上がっちゃってますが...
「JavaScriptでミリ秒単位の実行速度」があなたの気にしている「起動」だの「レンダリング」だのの体感速度にどのくらいの影響があるのでしょうか?
性能向上ってのは計測に基づき問題視されている部分に対して支配的な部分に手当てするのがセオリーであって、ほとんど影響を及ぼさないところにこだわってコストかけるのは正に「開発者の自己満足」と揶揄されても仕方ないでしょ。
そのあたりを明確にせずに長いコメント書いてもねぇ。
「絶対値ではなく比率だ」とぶち上げてますが、その前に問題区間に対しての割合を明らかにするべきでしょう。
例えば最初の描画完了までにかかるCPU処理時間が10ms短縮されたとして、それと並行して走っているNICからのデータ取り込み処理や、GPUでの描画処理、データ転送のDMAなどが律速要因であれば、まったく効果が無いわけですが。
また、5倍遅いPCでそれが50msになったとしても、数秒の中で一度だけ走る処理であればその差は体感影響にはつながらないですし。
もちろん、数百倍遅いPCであればその差は体感できると思いますが、それだけ遅いPCでは今回俎板にあがっている今時のブラウザでそもそも実用速度が出る気がしないのですが...
というわけで、「ブラウザ速度至上主義者」という割には「速度」に対して見識があるように見えず、元の指摘に対して的外れなコメントに見えます。実用評価に目もくれず、カタログスペックの○×に一喜一憂しているマニアさんのようですね :-)
はい。すくなくとも現在においてほとんどのWebサイトではその通りの結果になると思います。ボトルネックはHTMLとCSS処理です。サーバーが十分高速な場合はネットワーク速度の影響はあまり関係ないです。
ちなみに同じネットワーク速度でもWindowsMobileやゲーム機など非PC系の環境ではかなり遅く、レンダリング処理速度の重要性がわかりますが、まあ、自分のWindowsMobileの性能は Pentium 300MHz 程度という結果でさすがにPC環境とは差がありすぎるので別のお話です。
ちなみに純粋な描画処理による影響は(計測したことはありませんが)ほとんど無視できるレベルだと思っています。こちらは計測したわけではないので正確な根拠はありませんが、描画アクセラレーションがほぼ消えるVirtualPC上でブラウザを使っていても速度差を全く感じないので。VirtualPCではゲームなどは古いゲームでもあからさまに遅さを感じますから、純粋な描画処理の負担は数年前のゲーム以下であり問題ではないのだと思います。
もし描画処理でネックがあるとしたらむしろフォントレンダリングの速度ではないでしょうか。Wikipediaって意外と重いように思うので。
で、JavaScriptの実行速度はレンダリング速度にも影響を与えるわけですが、この処理が与える影響はブラウザゲームでもない限り、レンダリング完了までの体感速度に与える影響は、HTMLやCSSの処理速度に比べて小さく、まさにご指摘の通りです。はっきり言って現在のほとんどのWebサイトでは、HTMLやCSSの処理速度の方がよほど重要であると思います。
たとえば Yahoo トップを HTML のみで読み込んだ場合、自分の環境では通信を含めても200ミリ秒程度で処理が終わります。HTMLのみをRAMドライブにおいて読み込むと180ミリ秒程度で、ネットワークによる遅さは20ミリ秒程度であることがわかります。YahooにPINGしても10ミリ秒以下で返ってくるのでまあそれほど不思議な値じゃないと思います。逆に言えばほとんどの時間はHTMLレンダリングにとられていることがわかると思います。
同様にして画像やCSSやJavaScriptを調査していくと、処理時間の大きさは、HTMLの解析、次にJavaScript、次にCSSの処理です。CSSが70ミリ秒、JavaScriptが100ミリ秒かかっており、JavaScriptの影響は想像以上です。しかもコレはスクリプト処理が高速な Safari での結果で、スクリプト処理が遅いブラウザの場合にはさらに影響が大きくなります。一見それほどJavaScriptを使っているように見えないYahooでもこれだけの影響があります。実際にJavaScriptをオフにしてみると、アイコンやその他部分部分で差が出る程度で、その程度にしかJavaScriptは使われてないにもかかわらずです。
と、ここまで言っておいて逆説的ですが、現状では実際にはCSSの影響の方が大きいのが事実です。というのも、HTMLとCSSの解釈が終わらなければ画面表示が十分に始まらないからです。むしろHTMLとCSSの解釈が終わってしまうと、以後のスクリプト処理+画像ロード+その他の描画(フラッシュ等)、などはある程度平行して行えてしまうので、体感速度という意味ではHTMLとCSSの処理速度の方がよほど重要である、というのが間違いのない事実です。
ミリ秒単位でデータがダウンロードされてくることからもわかるように、通常のWebページであればネットワーク速度はもはやボトルネックとしては優先度が低くなっています。サーバー側の性能が不足している場合などはその限りではありませんが、ネットワークが遅いからブラウザを高速化しても無意味だという指摘は当たりません。光回線で得られる速度はもはや昔のディスクに匹敵するレベルにきています。(レイテンシとか安定性とかはともかくデータ転送だけなら)
ちなみに高速ブラウザではHTMLやCSSの処理もかなり高速化されており、決してJavaScriptだけが速いわけではありません。
自分が不満に思うのはJavaScriptベンチマークのたびに発言される「JavaScriptなんか速くなったって意味なくない?」という発言で、なぜJavaScriptが高速に処理できることを歓迎したり、それによってもたらされる新たな可能性を見いだせないのかという点です。ブラウザを単なる文書ビューアー以上にたらしめている最たる技術がJavaScriptであるはずなのに、なぜそれが遅いことが容認されるのか。ハードウェア系のベンチマークなら明らかに速いと賞賛されるだけの差があるのにスルーされていくのがとても不思議です。
同時に、タレコミ記事のようなベンチマークでは繰り返し回数を増やすなどしてより有意な差のつくベンチマーク手法でやってほしかったなとは思います。
と、ここまで言っておいて逆説的ですが、現状では実際にはCSSの影響の方が大きいのが事実です。 というのも、HTMLとCSSの解釈が終わらなければ画面表示が十分に始まらないからです。 むしろHTMLとCSSの解釈が終わってしまうと、以後のスクリプト処理+画像ロード+その他の描画(フラッシュ等)、などはある程度平行して行えてしまうので、 体感速度という意味ではHTMLとCSSの処理速度の方がよほど重要である、というのが間違いのない事実です。
そこで投機的解釈 [srad.jp]ですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
開発者の自己満足 (スコア:0)
JavaScriptでミリ秒単位の実行速度なんて開発者の自己満足だろ・・・。
ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:3, 興味深い)
決して開発者の自己満足ではないと思います。自分の考えでは、今までが遅すぎたのであって、今の速度競争は決して速度偏重に陥っているとは思いません。
自分も過去のブラウザ乗り換え履歴を思い返してきたのですが、ネスケ4に機能不足を感じつつも使っていたのはIE4の起動が遅すぎたからでしたし、
逆にIE5で起動が高速化されてからはネスケを起動することはなくなりました。Operaも「世界一高速」を謳っていたころに一時期使っていましたし、
今から思えば、DountLに乗り換えた時も最初の頃はタブブラウザよりも起動の軽さに魅力を感じていました。
同じことはFi
Re:ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:1, 興味深い)
なんか盛り上がっちゃってますが...
「JavaScriptでミリ秒単位の実行速度」があなたの気にしている
「起動」だの「レンダリング」だのの体感速度に
どのくらいの影響があるのでしょうか?
性能向上ってのは計測に基づき問題視されている部分に対して
支配的な部分に手当てするのがセオリーであって、
ほとんど影響を及ぼさないところにこだわってコストかけるのは
正に「開発者の自己満足」と揶揄されても仕方ないでしょ。
そのあたりを明確にせずに長いコメント書いてもねぇ。
「絶対値ではなく比率だ」とぶち上げてますが、その前に
問題区間に対しての割合を明らかにするべきでしょう。
例えば最初の描画完了までにかかるCPU処理時間が10ms短縮されたとして、
それと並行して走っているNICからのデータ取り込み処理や、
GPUでの描画処理、データ転送のDMAなどが律速要因であれば、
まったく効果が無いわけですが。
また、5倍遅いPCでそれが50msになったとしても、
数秒の中で一度だけ走る処理であればその差は体感影響にはつながらないですし。
もちろん、数百倍遅いPCであればその差は体感できると思いますが、
それだけ遅いPCでは今回俎板にあがっている今時のブラウザで
そもそも実用速度が出る気がしないのですが...
というわけで、「ブラウザ速度至上主義者」という割には「速度」に対して
見識があるように見えず、元の指摘に対して的外れなコメントに見えます。
実用評価に目もくれず、カタログスペックの○×に一喜一憂している
マニアさんのようですね :-)
Re:ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:2)
はい。すくなくとも現在においてほとんどのWebサイトではその通りの結果になると思います。ボトルネックはHTMLとCSS処理です。
サーバーが十分高速な場合はネットワーク速度の影響はあまり関係ないです。
ちなみに同じネットワーク速度でもWindowsMobileやゲーム機など非PC系の環境ではかなり遅く、レンダリング処理速度の重要性がわかりますが、
まあ、自分のWindowsMobileの性能は Pentium 300MHz 程度という結果でさすがにPC環境とは差がありすぎるので別のお話です。
ちなみに純粋な描画処理による影響は(計測したことはありませんが)ほとんど無視できるレベルだと思っています。
こちらは計測したわけではないので正確な根拠はありませんが、描画アクセラレーションがほぼ消えるVirtualPC上でブラウザを使っていても速度差を全く感じないので。
VirtualPCではゲームなどは古いゲームでもあからさまに遅さを感じますから、純粋な描画処理の負担は数年前のゲーム以下であり問題ではないのだと思います。
もし描画処理でネックがあるとしたらむしろフォントレンダリングの速度ではないでしょうか。Wikipediaって意外と重いように思うので。
で、JavaScriptの実行速度はレンダリング速度にも影響を与えるわけですが、この処理が与える影響はブラウザゲームでもない限り、
レンダリング完了までの体感速度に与える影響は、HTMLやCSSの処理速度に比べて小さく、まさにご指摘の通りです。
はっきり言って現在のほとんどのWebサイトでは、HTMLやCSSの処理速度の方がよほど重要であると思います。
たとえば Yahoo トップを HTML のみで読み込んだ場合、自分の環境では通信を含めても200ミリ秒程度で処理が終わります。
HTMLのみをRAMドライブにおいて読み込むと180ミリ秒程度で、ネットワークによる遅さは20ミリ秒程度であることがわかります。
YahooにPINGしても10ミリ秒以下で返ってくるのでまあそれほど不思議な値じゃないと思います。
逆に言えばほとんどの時間はHTMLレンダリングにとられていることがわかると思います。
同様にして画像やCSSやJavaScriptを調査していくと、処理時間の大きさは、HTMLの解析、次にJavaScript、次にCSSの処理です。
CSSが70ミリ秒、JavaScriptが100ミリ秒かかっており、JavaScriptの影響は想像以上です。
しかもコレはスクリプト処理が高速な Safari での結果で、スクリプト処理が遅いブラウザの場合にはさらに影響が大きくなります。
一見それほどJavaScriptを使っているように見えないYahooでもこれだけの影響があります。
実際にJavaScriptをオフにしてみると、アイコンやその他部分部分で差が出る程度で、その程度にしかJavaScriptは使われてないにもかかわらずです。
と、ここまで言っておいて逆説的ですが、現状では実際にはCSSの影響の方が大きいのが事実です。
というのも、HTMLとCSSの解釈が終わらなければ画面表示が十分に始まらないからです。
むしろHTMLとCSSの解釈が終わってしまうと、以後のスクリプト処理+画像ロード+その他の描画(フラッシュ等)、などはある程度平行して行えてしまうので、
体感速度という意味ではHTMLとCSSの処理速度の方がよほど重要である、というのが間違いのない事実です。
ミリ秒単位でデータがダウンロードされてくることからもわかるように、通常のWebページであればネットワーク速度はもはやボトルネックとしては優先度が低くなっています。
サーバー側の性能が不足している場合などはその限りではありませんが、ネットワークが遅いからブラウザを高速化しても無意味だという指摘は当たりません。
光回線で得られる速度はもはや昔のディスクに匹敵するレベルにきています。(レイテンシとか安定性とかはともかくデータ転送だけなら)
ちなみに高速ブラウザではHTMLやCSSの処理もかなり高速化されており、決してJavaScriptだけが速いわけではありません。
自分が不満に思うのはJavaScriptベンチマークのたびに発言される「JavaScriptなんか速くなったって意味なくない?」という発言で、
なぜJavaScriptが高速に処理できることを歓迎したり、それによってもたらされる新たな可能性を見いだせないのかという点です。
ブラウザを単なる文書ビューアー以上にたらしめている最たる技術がJavaScriptであるはずなのに、なぜそれが遅いことが容認されるのか。
ハードウェア系のベンチマークなら明らかに速いと賞賛されるだけの差があるのにスルーされていくのがとても不思議です。
同時に、タレコミ記事のようなベンチマークでは繰り返し回数を増やすなどしてより有意な差のつくベンチマーク手法でやってほしかったなとは思います。
Re: (スコア:0)
遅さを感じるのはブラウザよりもWebサイトの構成。
糞重たいFLASH広告を表示してからやっと本文を読み込むようなサイト。
未だにPHSの通信カードを使う場合がありますが、本文が表示されるまではイライラしますね。
Re: (スコア:0)
そこで投機的解釈 [srad.jp]ですよ。