人気が出れば出るほど、Webブラウザは遅くなる 107
ストーリー by mtakahas
てことは遅くなればなるほど人気が出る……わけないですね 部門より
てことは遅くなればなるほど人気が出る……わけないですね 部門より
pinbou 曰く、
本家/.の記事(Slashdot | The More Popular the Browser, the Slower It Is)より。Webブラウザの速度ベンチマークPeacekeeperの集計結果によると、人気のあるブラウザはそうでないものに比べてパフォーマンスが劣るという結果が出た。
IEが遅いというのは予想の範囲内だろうが、FirefoxもSafariやGoogle Chromeと比べると相当遅い。そう遠くない未来、多くの人が「Firefoxは遅くて仕方がない」とぶうぶう文句を言ったり、あるいはJavaScriptを駆使したGoogleのWebアプリはChromeでないと実用的なスピードで動かない、なんていう日が来るのだろうか?
ここで取り上げられているPeacekeeperは、JavaScriptの処理に特化したベンチマークですね。ほかの指標だとまた違う傾向が出るのでしょうか。
当然の帰結では? (スコア:5, すばらしい洞察)
「人気が出る=最小公倍数の拡大」と捉えれば
・機能を拡大し単純に肥大化した
・速度(各レスポンス)より優先すべき事項が増えた
帰結として遅くなるのは自明の理に感じます。
つまり、この結果は逆説的に
「多くの人にとって、速度より優先する機能がブラウザには存在する」
という証明にもなっているのではないでしょうか。
Re:当然の帰結では? (スコア:1)
それぞれのブラウザの成り立ちを考えると、その説は間違っていると思います。
後発ブラウザほど速いのは、乗り換えてもらうための動機付けとして、速度性能が重視されて開発されていることが、この結果につながっているのではないでしょうか?
http://srad.jp/it/comments.pl?sid=451376&cid=1571670 [srad.jp] のACさんがすでに指摘していますが、ミリ秒単位の速度なんて開発者の自己満足だと常々感じていました。「多くの人にとって、速度より優先する機能がブラウザには存在する」ということはまったくもって同意できるところです。
速度性能だけを重視することは間違っていると思いますが、他の性能を向上させるよりもアピール可能な水準に達するまでの開発コストが安く済むことや、速度は数値で表せるので比較しやすいことも、速度偏重に陥っている理由と考えています。
Re:当然の帰結では? (スコア:1)
遅いのには理由は無いって言いたかっただけです。
加えて、じゃあなんで速度重視なの?ということを考察しました。
同意です。いくつかあるニッチターゲットのうち、わかりやすい速度が選ばれたんだと考えました。
比較結果がはっきり出るから、非常に限定された領域のはずなのに、ブラウザ全体の優劣のように見えてしまうと思います。我々以外には。
Mozilla陣営は遅いというレッテルを貼られて黙ってはいられなかったんでしょう。
Re:当然の帰結では? (スコア:1)
そうすると、どうしても速度を犠牲にしても機能を充実させ動作を安定させる必要も出てくるでしょう。
スポーツカーとファミリーカー、スポーツカーの方が「速い」のは自明であっても多くの人に選ばれるのはファミリーカー、というアナロジーがそこそこ当てはまると思います。
Re:当然の帰結では? (スコア:1)
1位. IE - 以前はFirefoxよりもJavaScriptの実行が高速だった。相対的に遅くなったのは高速化を怠ったため。単純にデフォルトだからシェアが高い。
2位. Firefox - 前身のMozillaの頃から遅かったが、バージョンアップごとに高速化してきた。
3-5位. Opera, Chrome, Safari - 後発なので差別化のために速度を重視した。
こんな感じじゃないでしょうか?
そもそも遅くなったという事実が無いので、ユーザーが増えると遅くなるという説は、Webブラウザに関しては成り立たないと思いますよ。
元記事はJavaScriptのベンチマーク結果を元にした仮説ですが、体感速度に関しても遅くなったのはIE7,8くらいかと。最近のFirefoxが遅いとしたら、それはアドオンの入れすぎであって、素のFirefoxは少しずつ速くなってきています。
Re:当然の帰結では? (スコア:1)
付け加えておきますね。。
http://srad.jp/it/comments.pl?sid=451376&cid=1571695 [srad.jp] のACさんも良いことを言ってます。
Re:当然の帰結では? (スコア:1)
絶対的な速度で言えば、「遅くなったという事実が無い」と言うのはその通りだと思います。
ただメジャーになれば速度向上以外に気を配らなければならなくなる部分が大きいので、後発の新興ブラウザほど速度向上に力を注げず、結果的に相対的に「遅くなる」のだと思います。
あと、「アドオンの入れすぎ」という点では、メジャーなブラウザほど色々なアドオンが豊富に出回っていて、またアドオンのインストールが求められるサイトも少なくないので、どうしても入れ過ぎになりがちなのかもしれません。
Re:当然の帰結では? (スコア:1)
元コメ http://srad.jp/comments.pl?sid=451376&cid=1571674 [srad.jp] について、Webブラウザ以外の一般論としてなら、すば洞で同意なんですが、限定的なベンチマーク結果と現時点のシェアを比べただけの「今こうなってるよ!」というレポートに法則性を見出していることが引っかかったんです。
IEが最速だった時代を説明できないですし。
それから、Firefoxは最初から重厚だったから肥大化なんてしていないわけで。
Re:当然の帰結では? (スコア:1)
何処に付けようか迷ったけどここに。
昔の「Phoenix」や「FireBird」が残っていたりしますが、
起動時間は現行のFirefox(素のまま)に比べて凄く早く感じますね。
普段使ってるFirefox(IEタブ+NoScript+Adblock+ScrapBook+中止ボタンがしいたけ)では比較するまでもないw
レンダリング自体は差を感じられませんけども。
色々変更された結果、便利になりつつも重くなっているのだなぁと実感出来ます。
ψアレゲな事を真面目にやることこそアレゲだと思う。
Re:当然の帰結では? (スコア:1)
これは昔からあるセカンドシステム効果の典型例でしょう。
シンプルで軽快なソフトウェアが登場し、人気がでる。
でもって様々な要望が集まり、実装され、結果として複雑で重くなっていくと。
盾と矛 (スコア:3, すばらしい洞察)
自国の次期主力戦車の主砲は、仮想敵国の主力戦車の正面装甲を打ち抜ける
ように作るもんじゃないでしょうか。
Firefox3という主力戦車の正面装甲(スピード)を打ち抜けるような主砲を装備する
ことは、Google Chromeに求められた要求仕様そのものだったのではないかなあと。
そしてその仕様が十分に満たせなければ、失敗作として歴史の表舞台にたつ
ことさえないまま、ひっそりと消えていくのです。
つまり「人気のないブラウザは、人気のあるブラウザより『早い』などの分かり易い
指標で勝ってなければならない」だから結果だけ見ると、「人気が出れば出るほど、
Webブラウザは遅くなる」ということになるんではないかと。
#もちろんサンプル数が少なすぎるというのもあるけど。
Re:盾と矛 (スコア:1, 興味深い)
たしかにそれが望ましいが、必ずしもそうとは限らない。仮に相手の正面装甲を打ち抜くほどの巨砲を積むには自分の装甲を相手に打ち抜かれる程度まで減らさなければならないならば、そんなことはすべきではないから。何だって要はバランスだ。実際のところ、現代の大抵の国は自分の装甲を自分で打ち抜けない程度の主砲を積んでいる。
Re:盾と矛 (スコア:1)
今となっては撃ち抜く必要はないかも知れず。
というのは撃ち抜けなくても衝撃で中の人が...という状況なので。
# T90はそれ自身の主砲の至近射撃に耐えられるが、試験の時に衝撃で中の豚さんが...というのは有名な話。
## 人の重さ人形じゃダメなんだろうか。
ブラウザの方は、互換性の高さとパフォーマンスがトレードオフになってるような気がしなくもない。
あるいは人気が出ていろいろ付け加えられて重くなる...みたいな。
Re:盾と矛 (スコア:1)
無料で配布されてるブラウザが多いので、もう安価はウリにならないし。
そしたらもう機能と速度は殆どの場合トレードオフですよねぇ。
# 硬い戦車は重くて遅い。軽い戦車は速いが弱い。
## 正面から撃ち合うか、回り込んで背後をつくか。戦局によっても要求される性能は違ってくるわな。
# でもな、要求は大体『速くて硬くて軽くて強い戦車を作れ』なんだよ。
ちょっと違うかと・・・ (スコア:2, すばらしい洞察)
あまり使われていないブラウザが早いと言うお触れで出回る。
みんなが使い始める。
みんなが使い始めるので、「これは早いブラウザ」が「これが普通」になる。
ユーザが多いのでちょっとでも遅いと感じることがあると「遅い」と言い出す輩が増える。
ということは (スコア:1, おもしろおかしい)
かというとそんなわけはなく,むしろ
「人気がなければ早くなくなる。」
Re:ということは (スコア:1)
「人気があるから、高速しなくてもいい」というのと「人気得るためにも、高速化しないといけない」という考えも…
/* Kachou Utumi
I'm Not Rich... */
Re:ということは (スコア:1)
人気がない → フィードバックが少ない → シンプルなまま
あとはオプソかプロプラかってのも関係あるだろうなぁ。
結局 (スコア:1, 興味深い)
人気が出るとユーザの求める機能を追加していくことによって遅くなっていくのかな?
任期がないブラウザほど機能的には貧弱だけどその分速度的に有利になるとか・・・・
パフォーマンス (スコア:1, 興味深い)
FirefoxはJavaScriptベンチマークではボロ負けだけどロードタイムは最速 [hatena.ne.jp]みたいですよ。
これが筆者の言うとおり、単純に投機的解釈とやらのおかげなら、そう遠くない未来に他のブラウザにも実装されて、JSと同じようにボロ負け状態になるのは目に見えてますけどね。
低シェア低速度は投資対象にならない (スコア:1)
開発に貢献するにせよ、投資対象として的確かどうかがまず評価される。市場占有率が
低く、しかも現在主流のブラウザに対して速くもないとすれば、そんなブラウザ技術は
資金や人材の投資を得られずに野垂れ死んでしまう。
いま生き残っているブラウザ技術は、シェアとスピードの合計得点でなんらかの基準を
クリアしているから、継続的改善のための投資が回ってくるのだ、と考えることができる。
既にFirefoxはものすごく重い (スコア:1, 参考になる)
同等のタブ数を同時に開くと、明らかに重くなったと感じる。あとメモリ消費も激しい。ディスクアクセスも多い。
jsがIEより速いかどうかと言った話ではFirefoxのほうが素性がよいのだろうけど、タブが増えるとjsが極端に低速化するとか、
膨大なメモリを要求して解放しないといった面まで考慮すると、以前言われていたほどのIEからの優位性はあるのか疑問だ。
一部の誇張された風説に騙されてFirefoxに移行したユーザが居ないか気がかり。ブラウザの選択肢が増えたのだから、
用途や環境を踏まえてどちらがお奨めかという話にした方がよいだろう。あらゆる面でIEより優れているので無い限り。
つまるところ、IEのようにコンポーネント化されてパーツとして使える形状に重きを置いた方がユーザにとっては便利かも知れない。
それだけ1つのブラウザの不具合から一時的に逃げられる可能性を高められる。
Re:いちいちZIP展開してるから? (スコア:1, 参考になる)
改造て、コンパイルするとき--enable-chrome-format=flatを指定するだけやん。
ちなみにMozilla曰く
「これはデバッグ用だハゲ。Debianは長年これつけてるが、そいつはバグだぜヒャッハー(湾曲」
Re:いちいちZIP展開してるから? (スコア:1)
わんきょく……婉曲 [goo.ne.jp]でなく?
Re:既にFirefoxはものすごく重い (スコア:1)
さわったこともないものを出されてもなぁ~
the.ACount
iCabで実感 (スコア:1)
Mac OS 9 時代ですが、ちょっぱやで一時流行った iCab [mac.com] というブラウザがあり
ベータの段階からものすごい早さを叩きだしていたんですが
人気が出たからか、正式版になりCSS対応になった途端に激重。
ベータ版は期限付きで継続使用はできず、しぶしぶ最新版を使ってみたりはしてましたが
それ以降早さを取り戻すことはなく今ではその名を知るものも少数になってしまいました。
CSSなんかいらない、あたし早い人がいいの。と思ったあの日が懐かしいです。
# ほんとに早かった、あのブラウザは本当に早かった。
Re:iCabで実感 (スコア:1)
CSSがなんなのかもわからなかった当時の自分には他の便利さはわからなかったことを反省^^;
開発者の自己満足 (スコア:0)
JavaScriptでミリ秒単位の実行速度なんて開発者の自己満足だろ・・・。
ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:3, 興味深い)
決して開発者の自己満足ではないと思います。自分の考えでは、今までが遅すぎたのであって、今の速度競争は決して速度偏重に陥っているとは思いません。
自分も過去のブラウザ乗り換え履歴を思い返してきたのですが、ネスケ4に機能不足を感じつつも使っていたのはIE4の起動が遅すぎたからでしたし、
逆にIE5で起動が高速化されてからはネスケを起動することはなくなりました。Operaも「世界一高速」を謳っていたころに一時期使っていましたし、
今から思えば、DountLに乗り換えた時も最初の頃はタブブラウザよりも起動の軽さに魅力を感じていました。
同じことはFireFoxでもいえることで、最初は遅くなるのが怖くてプラグインは入れなくなりましたし、ばりばり使うようになってもプラグインの自動更新は常々じゃまだと思っているところにChromeが登場。
で、今はChromeを使っていて、FireFoxはプラグインが必要な時をのぞき滅多に起動しなくなりました。
ちなみにSafariもかなり高速で一時常用していましたが、やはりレンダリング速度はChromeが最速に感じます。
ミリ秒単位の速度差が無意味だとおっしゃる人は多くいますが、そもそも全てのWebページ、全てのPCでミリ秒の差しかないわけじゃありません。
測定環境の半分の性能のPCなら2倍遅いですし、測定ベンチの10倍重いページなら10倍の差が出るわけです。で、JavaScriptはともかくレンダリングが重いページはいくらでもあります。
さらに自分の用に、毎日タブでまとめて開くブックマークが18個ある(スラド含)場合、速度差が積み重なるので18個開ききるまでの差は相当のものになります。
Chromeが当然のごとく18個をスムーズに開いていくのをみていると正直FireFoxやIEを常用する気にはなれません。(あくまで自分個人の感想です)
言うまでもないことですが、なら毎日開くお気に入りを減らせ、という意見はPC性能(今回はブラウザ性能)が不足しているから妥協する、ということに過ぎませんよ?
(ちなみにRSSは登録サイトが増えるとウザすぎるので使わなくなりました)
で、速度が速くなるとキーワードを検索し直すのも画像を見るためだけにタブを同時に30個開くのも苦にならないわけで、必然的にプラグインの必要性も低くなります。
今までFireFoxでやたらプラグインを導入してたのも速度が遅いのをカバーするためだったような気さえしています。
Vistaが(実際に使っているとそれほどでもないにもかかわらず)世間でやたら遅いと酷評されているのも、IE7が遅すぎたからじゃないかという説もあるほどです。
(実際IE6よりも7はページレンダリング速度とスクロール速度がかなり落ちているように自分は感じていました)
「OS==ブラウザ」である人たちにとってみれば「 if ( IE7.速度 == 遅い ) ブログ.Write( "Vista遅い" ); 」になってしまう可能性は十分あるかと。
その反省かIE8はIE7に比べれば明らかに高速化されていると思います。記事はJavaScriptベンチですがレンダリングならFireFoxとの差はかなり薄まっている印象です。
同時に、ブラウザ開発者でなくWebページ開発者にとってみれば、ミリ秒も差があるというのは相当な違いになることもあるかと思います。ミリ秒の差といっても絶対値ではなく比率であることを忘れてはなりません。
記事の例に限って述べるのであれば、おおざっぱに言ってマイナーブラウザは人気ブラウザの5倍程度の速度を実現していることになると思われますが、
表示に5秒かかるから実装は見送りになってしまったが、もし1秒だったら実装できた、というサイト機能があってもおかしくありませんし、
記事では Core2 E6400 を使っていますが、もしこれが Atom なら上記の数倍の速度差がある、ということも忘れてはなりません。
長文失礼しました。
ブラウザ速度至上主義者(ある程度以上のレンダリング互換性があるならば)の1人としてこれだけはいわせて頂かなくてはなりませんでした。
絶滅間近の種族であるブラウザ速度至上主義者の生き残りの遠吠えに過ぎませんので皆様あまり気になされずに。
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:ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:1)
少なくともブラウザによって体感レベルの差は出ます。あとFireFoxって1つのタブで読み込みが遅くなるとそれ以降のタブまで止まるんですよ。
なのでFireFoxをメインにしていた頃はブックマ-クの並び順を変えて、軽いペ-ジから順番に開くようにしていました。
Re:ブラウザに求めることは1が正確なレンダリングで2が速度、34がなくて5がオマケ機能。 (スコア:1)
IEしか動かないサイトのために時々IEを立ち上げるんだけど起動遅くてイライラするなぁ。
ブラウザはほぼ毎日開くものなのでOSの起動時間と同じくらい早さは重要に思います
Re:開発者の自己満足 (スコア:2, すばらしい洞察)
Re:開発者の自己満足 (スコア:1)
ミリ秒単位で画面上のオブジェクトを動かしたりするときは多少差が出ますが、
テキスト処理関連で困ることはだいぶ減ったように思います。
ただしIEはこんな感じのコードでボタンを連打しても反応がすごく遅い問題がずーっと直らないです。
Re:開発者の自己満足 (スコア:3, 参考になる)
> ボタンを連打しても反応がすごく遅い問題がずーっと直らないです。
これは、「ボタンを連打する」と「ダブルクリック」になってしまうからでしょう。
IEのボタンは、ダブルクリックに反応しない
Firefoxのボタンは、ダブルクリックにも反応する
ということで、反応が遅いわけではないと。
Re:開発者の自己満足 (スコア:1)
IEに関してはそれで問題を回避できますね。
でもそれだけだとIE以外のブラウザがダメなので、
IEとそれ以外でコードを分岐する必要があります。
とりあえずこんな感じでしょうか。
addEventListnerとAttachEventの有無でブラウザ判定しています。
Re:開発者の自己満足 (スコア:2, 興味深い)
この件は、ブラウザの仕様(バグ?)であって、
直接的な処理速度の話ではないですね。
でも、JavaScriptが速ければ無駄な処理が増えても遅延が顕在化しない、
ということはあると思います。
せっかくなので私なりの意見を書いておくと、
JavaScriptの高速化のおかげで、
ミリ秒単位のコーディングがしやすくなりました。
これは開発者の自己満足ではなくて、
JavaScriptの可能性が大きくなっているのだと思います。
FlashでやっていたようなエフェクトがJavaScriptでもなめらかに動かせるし、
JavaScriptは速ければ速いほどいいです。
でも、JavaScriptの処理速度がブラウザの謳い文句になるほど、
エンドユーザに対して訴求力のある話ではないかもしれません。
あくまでも縁の下の進化というか。
Re:開発者の自己満足 (スコア:1)
おおよそ、30msが時間感覚の分解能だと聞いています。(時間順序判断分解能・こっちの方が早かったと判り始める速度)
なので、1~2msの速度に血道を上げるのは開発者の自己満足ですが、30msを超える速度アップは我々にも恩恵があるかと。
(1msの高速化x30を繰り返すことで、体感速度が上がっていく)
# もちろん、フル・アニメーション(42ms)とリミテッド・アニメーション(125ms)の差が表現力の差でないことは、日本人であれば誰しも理解していることではありますが:p
Re:JavaScriptの部分だけ別にできないの? (スコア:2, 興味深い)
ブラウザ実行中に自由に切り替えたいということでしたら、それは実現できていませんけど。
Re:JavaScriptの部分だけ別にできないの? (スコア:1, 参考になる)
IEでは、ブラウザとスクリプトは分離されています。
フレームワークの名称がActive scriptingで、スクリプト言語のホスト(実行環境)として、
WebブラウザやWebサーバやWindows OSを選択できます。
スクリプト言語として、VBScriptやJScript(JavaScript)、PerlやPythonなどが選択できます。
http://ja.wikipedia.org/wiki/ActiveX_Scripting
JScriptのエンジンを(MSのものとV8とみたいに)2つインストールして、両者を選択できるのかは知りません。
Re:JavaScriptの部分だけ別にできないの? (スコア:1)
# WebKitが紹介されているので
IEもそうなってますよ。JavaScript(JScript)のほかにVBScriptが用意されていて、interfaceも公開されてます。
ActivePerlを使っている人は知ってると思うけど、ActivePerlをインストールするとPerlScript [activestate.com]も書けますよ。
IE8でもまだ遅いと言われますが、script interfaceとDOM interfaceの両方を維持しながらよくやった方なのでは。
Firefoxの詳しい事情は知りませんが、JavaScriptエンジンを切り替える話が出ているところから推測するに切り離し可能なのでは。
Re:開発者の自己満足 (スコア:2)
全体の処理が秒単位のときに 100ms 違っても問題になりにくい気はします
あと今の液晶ディスプレイだとそれこそフレーム単位で遅延が入りますが
気にしてるのは一部のアクションゲーマーだけのような
やっぱり (スコア:0)
Re:ブラウザの軽さ (スコア:1, 興味深い)
Google ChromeやIE8はタブを別プロセスにしてるんだろ。
単にタブを開くだけのベンチマークだと不利になるのは当然。
それからあらかじめメモリを多めに確保するのとメモリリークしてるのも話が別だからな。
ちなみにIE6みたいにメモリを少なめに確保するものは最近では希少種で、JavaScriptを
バリバリ使うを前提にしてるとか富豪的なアプローチに向かっている。
Re:ブラウザの軽さ (スコア:1)
HKLM (or LKCU) \ Software\Microsoft\Internet Explorer\Main\TabProcGrowth
DWORD : TabProcGrowth
値 : 1
で、新規タブを作る時に新しいプロセスを作らなくなるので (IE7 までのように全タブが同一プロセス) 、動作は早くなるのではと思います。
Re:ブラウザの軽さ (スコア:1)
IE8の新規タブは履歴リストやアクセラレータの読み込みがあるので、そのせいでは?
新規タブを「空白のページ」にしても同様の遅延が発生しますか?
Re:初めて言えた (スコア:1)
seamonkeyで見ている俺の勝ち
Re:初めて言えた (スコア:1, おもしろおかしい)
Re:初めて言えた (スコア:1)