アカウント名:
パスワード:
Chromeの高速化へこだわり(2008年時点) [atmarkit.co.jp]読む前から、なんとなくサクサク動くなと感じていたが、他のブラウザがのきなみ遅くなるのを感じて以来ほぼこれ一本です。
ＩＥ指定の部分だけ用にＩＥも併用するが
Chromeはメモリ使用量を抑えるようなテクニックを使っているわけではないので、この件とは正反対だね。
普通のエディタ、って言うと語弊があるかもしれないけど、例えばバイナリエディタとかだと、そもそも表示部分以外はメモリにロードしないことすらある。だから、対象のファイルがテラバイト単位でも、即座に表示される。
でも、HTMLでそれをやるのは難しい。なんでかっていうと、まず、ソースがネット越しのストリームだから。そして、HTMLは最後までパースしないと、不整合が起きる可能性があるから。だから、メモリをバンバン使う方向は正しい。
でも、「大量の画像」を表示させると、どのブラウザでも簡単にフリーズする。実メモリの容量を超すのがすごく簡単だから、一気に仮想メモリまで行ってしまうわけだ。だから、見えない部分をロードしない、ってのはアリだと思うけど。
>そして、HTMLは最後までパースしないと、不整合が起きる可能性があるから。だから、メモリをバンバン使う方向は正しい。
HTMLだけが使うメモリって知れてるんよね。
HTMLが使うメモリってのは、もちろん、レンダリング「された」内容も含んでのことだよ。HTMLだって、単体のテキストじゃ微々たるものだけど、それを展開したあとのセマンティックな「画像」になるとメモリをたくさん食う。しかし、「HTMLを半分だけレンダリングする」ってのは、あんまり現実的じゃないんだよ。
上から○○ピクセル、左から××ピクセルの色、とかは、順番に展開していかないと決められない。
レンダリング結果のDOMツリーにしても、画像に比べたらたかが知れてる。
しかもこれはデコード後の結果(つまり圧縮を解いたあとのメモリイメージ)を今まで後生大事に抱えていたという話。そりゃ簡単に数GB使うわけだ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
chromeあるからイラネ！（AA略) (スコア:1)
Chromeの高速化へこだわり(2008年時点) [atmarkit.co.jp]読む前から、なんとなくサクサク動くなと感じていたが、
他のブラウザがのきなみ遅くなるのを感じて以来ほぼこれ一本です。
ＩＥ指定の部分だけ用にＩＥも併用するが
Re: (スコア:0)
Chromeはメモリ使用量を抑えるようなテクニックを使っているわけではないので、この件とは正反対だね。
普通のエディタ、って言うと語弊があるかもしれないけど、例えばバイナリエディタとかだと、そもそも表示部分以外はメモリにロードしないことすらある。だから、対象のファイルがテラバイト単位でも、即座に表示される。
でも、HTMLでそれをやるのは難しい。なんでかっていうと、まず、ソースがネット越しのストリームだから。そして、HTMLは最後までパースしないと、不整合が起きる可能性があるから。だから、メモリをバンバン使う方向は正しい。
でも、「大量の画像」を表示させると、どのブラウザでも簡単にフリーズする。実メモリの容量を超すのがすごく簡単だから、一気に仮想メモリまで行ってしまうわけだ。だから、見えない部分をロードしない、ってのはアリだと思うけど。
Re: (スコア:0)
>そして、HTMLは最後までパースしないと、不整合が起きる可能性があるから。だから、メモリをバンバン使う方向は正しい。
HTMLだけが使うメモリって知れてるんよね。
Re:chromeあるからイラネ！（AA略) (スコア:0)
HTMLが使うメモリってのは、もちろん、レンダリング「された」内容も含んでのことだよ。HTMLだって、単体のテキストじゃ微々たるものだけど、それを展開したあとのセマンティックな「画像」になるとメモリをたくさん食う。しかし、「HTMLを半分だけレンダリングする」ってのは、あんまり現実的じゃないんだよ。
上から○○ピクセル、左から××ピクセルの色、とかは、順番に展開していかないと決められない。
Re: (スコア:0)
レンダリング結果のDOMツリーにしても、画像に比べたらたかが知れてる。
Re: (スコア:0)
しかもこれはデコード後の結果(つまり圧縮を解いたあとのメモリイメージ)を今まで後生大事に抱えていたという話。そりゃ簡単に数GB使うわけだ