Firefox 41、14年前に報告されたバグの修正でAdblock Plus使用時のメモリー消費量が大幅に減少 44
ストーリー by headless
現象 部門より
現象 部門より
22日にリリースされたFirefox 41.0では、Adblock Plus使用時のメモリー消費量に関する問題が解消している(Adblock Plusのブログ記事、
VentureBeatの記事)。
Adblock Plusではエレメントを非表示化するために単一のスタイルシートを使用するが、旧バージョンのFirefoxでは各ページを読み込む際にスタイルシートのコピーを作成する。スタイルシートが使用するメモリーは数MB程度だが、iframeを含むページではiframeの数だけスタイルシートのコピーが作成されるため、メモリー使用量が大幅に増加することがある。極端な例としては、428個のiframeを含む「VIM Color Scheme Test」を表示する場合、Adblock Plusを有効にするとメモリー使用量が1GB以上増加していた。
Adblock Plus使用時にメモリー消費量が増加する問題は2014年3月にBugzillaで報告(バグ988266)され、同年5月にMozillaとAdblock Plusの開発者が確認していた。この問題の大元になっているのはFirefox誕生前の2001年4月に報告されたバグ77999であり、バグ77999が修正されてスタイルシート関連のデータを共有可能になったことで、バグ988266の修正も可能になったとのことだ。その結果Firefox 41.0では、Adblock Plusを有効にしてVIM Color Scheme Testを読み込んだ際のメモリー使用量が以前のバージョンから1GB以上減少している。
なお、Google ChromeでもAdblock Plusを有効にしてVIM Color Scheme Testを読み込むとメモリー消費量が大幅に増加することが確認できた。また、AdBlockなど他の広告ブロック拡張機能でも同様の現象が発生するようだ。
Adblock Plusではエレメントを非表示化するために単一のスタイルシートを使用するが、旧バージョンのFirefoxでは各ページを読み込む際にスタイルシートのコピーを作成する。スタイルシートが使用するメモリーは数MB程度だが、iframeを含むページではiframeの数だけスタイルシートのコピーが作成されるため、メモリー使用量が大幅に増加することがある。極端な例としては、428個のiframeを含む「VIM Color Scheme Test」を表示する場合、Adblock Plusを有効にするとメモリー使用量が1GB以上増加していた。
Adblock Plus使用時にメモリー消費量が増加する問題は2014年3月にBugzillaで報告(バグ988266)され、同年5月にMozillaとAdblock Plusの開発者が確認していた。この問題の大元になっているのはFirefox誕生前の2001年4月に報告されたバグ77999であり、バグ77999が修正されてスタイルシート関連のデータを共有可能になったことで、バグ988266の修正も可能になったとのことだ。その結果Firefox 41.0では、Adblock Plusを有効にしてVIM Color Scheme Testを読み込んだ際のメモリー使用量が以前のバージョンから1GB以上減少している。
なお、Google ChromeでもAdblock Plusを有効にしてVIM Color Scheme Testを読み込むとメモリー消費量が大幅に増加することが確認できた。また、AdBlockなど他の広告ブロック拡張機能でも同様の現象が発生するようだ。
Google Chrome 47.0.2516.0 dev + uBlock Originのテスト (スコア:4, 参考になる)
VIM Color Scheme Testのメモリ消費をテストしました。
uBlock有 420,220K
uBlock無 61,072K
Firefox程でないにしろ、AdBlock以外でもメモリの消費が多くなることを確認しました。
Re:Google Chrome 47.0.2516.0 dev + uBlock Originのテ (スコア:1)
Firefox 41、32bit環境では固まって起動すらできなかった・・・・
Re:Google Chrome 47.0.2516.0 dev + uBlock Originのテ (スコア:1)
すんません、誤解を招くような書き方で。
×起動すらできなかった
○VIM Color Scheme Testのページを開く事すらできなかった
Re: (スコア:0)
むしろ増えるのが当たり前では？
縦書き対応 (スコア:3, 興味深い)
これで現行のほぼすべてのブラウザでルビと縦書きが使えるようになった。
Re:縦書き対応 (スコア:1)
超絶に汚かったCSSアニメーションがやっと改善された。
ESRにも適用でしょうか。 (スコア:1)
Re:ESRにも適用でしょうか。 (スコア:2, 参考になる)
ESR 45.0に反映されます。
Re:ESRにも適用でしょうか。 (スコア:1)
早くて来年の3月かぁ (スコア:0)
http://www.mozilla.jp/business/downloads/ [mozilla.jp]
結論からゆーと (スコア:0)
iframe滅ぶべし！！
Re:結論からゆーと (スコア:1)
滅ぶなんてとんでもない
HTML5で新機能を大量追加しましたから使う気満々ですって
sandboxあたりは主要ブラウザで実装終わったんじゃないかなー
Re: (スコア:0)
便利なんだけど他から見たら本当にマイナスしかないんだよね…
これアップデートしても (スコア:0)
メモリ1GBのWindowsタブレットじゃきっついきっついで素直にedge使った方がいいのかなって気がして…
タブレットモードへの対応も中途半端すぎますもんねぇ
Re:これアップデートしても (スコア:1)
なにか言い返してやろうと思ったが、低スペックなのにメモリだけ2G積んでる廉価スマホが想像以上に軽快なのもあって、言い返す言葉が浮かばなかった
Googleまたは端末メーカーは根本的に自分たちの失敗を認めるところからスタートすべき
Re: (スコア:0)
Androidで1GBだとゴミクズカス呼ばわりされるのにやっぱりWindowsは優秀ですね。
Re: (スコア:0)
Android 5.0はメモリリークが酷くて2GBマスト、4GBベターみたいな状況でしたしね。
Windowsは仮想メモリで追い出したりCPUパワーでメモリ圧縮出来るとはいえ、本気になったMSは資金力でごり押して実現しちゃう辺りは凄いですな。
Re: (スコア:0)
AndroidというかLinuxにも似たような機能はあるんですが、端末メーカーが有効にしていないだけです。
Re: (スコア:0)
新しいタブレットを買うのが最適解かと。2GBのタブレットなら20000からでもあります。
メモリ1GBはストレス分の損失が大きすぎると思います。
どうしても現状でがんばるのならオンメモリのタブ数の自制は必須かと。
バージョン41? (スコア:0)
すぐに1000を超えそう。
週替わりでアップデートされるのはバグが多い？それとも良心的？
Re:バージョン41? (スコア:1)
masakunのコメント [apple.srad.jp]がツボに入ったらしい人はもう飽きたのかな。
Re: (スコア:0)
そのツリー、みんなが少しずつズレてて何か気持ち悪いですね。
Re: (スコア:0)
>すぐに1000を超えそう。
1000を越えるのは120年後ですが
Re:バージョン41? (スコア:1)
エルフである可能性
それはそうと (スコア:0)
Firefoxそのものが元々メモリ食いなわけで、個人的にはそっちのほうを先になんとかしてほしいのですが。
これについてはいっそのこと一から設計し直すとかしなきゃダメなのかな?
Re:それはそうと (スコア:1)
閉じたウインドウとかタブで使っていたメモリをきちんと回収したらいいと思うんですけどね
Re:それはそうと (スコア:1)
malloc/free ではすぐには回収されないからね
独自のメモリプール使っても、肥大化は抑えられても解放は結局同じだし
Chrome みたくプロセスごと Kill するのが解放するには一番いい
トータルのメモリ使用量は一気に増えるだろうけど……
# 昔のメモリ解放ソフトみたく、瞬間的に大量に確保して仮想メモリに追いやったらどうだろう
# 仮想メモリ 0 にしてる私の環境では死ぬだろうけど
Re: (スコア:0)
malloc/freeはアプリ内のプールへは即座に返却される。
一方システムにはいくら待っても返却される保証はない。
独自のメモリ管理をしたうえでOSのメモリ管理API叩きましょう。
# 昔のメモリ解放ソフトみたく、瞬間的に大量に確保して仮想メモリに追いやったらどうだろう
Fxには以前ウィンドウ最小化でワーキングセットが縮小してそういう効果が得られる的なTipsがあったような。
つか仮想メモリに追いやってもメモリ(仮想メモリ)は開放されないからバカ食いの問題自体は解決しないぞ？
Re: (スコア:0)
メモリの議論はニワカと自称中級者が印象だけでFUDを繰り返しているからもうどうしようもない。
Re: (スコア:0)
勉強になります
> 独自のメモリ管理をしたうえでOSのメモリ管理API叩きましょう。
メモリ管理 API 直叩きならすぐにシステムに返却されるんですね、知らなかったです
ただ OS 毎に別コードになるのは面倒ですね
> つか仮想メモリに追いやってもメモリ(仮想メモリ)は開放されないからバカ食いの問題自体は解決しないぞ？
以前携わっていたアプリが、大量にメモリを喰った後大幅にメモリ使用量が減るという現象があったので、
強制 GC のようにシステムへの回収をキックできるのではと思いました。
ただ根拠はないです。
Re:それはそうと (スコア:1)
Firefoxはjemallocというmallocの独自実装を使っています。
https://github.com/jemalloc/jemalloc [github.com]
http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/ [mozilla.org]
memory fragmentationとかでググってみてください。
Re: (スコア:0)
unloadtabを使ってタブは残しつつ、メモリーだけ開放するとか。
https://addons.mozilla.org/ja/firefox/addon/unloadtab/?src=api [mozilla.org]
configuration-maniaを使って、1タブあたりのキャッシュ数を制限するとか
ブラウザ／ブラウザのキャッシュ／キャッシュされるページ表示の数
https://bitbucket.org/cat_in_136/configuration-mania/wiki/Home [bitbucket.org]
Re: (スコア:0)
bfcacheが気に入らないなら、network.http.use-cacheをfalseにすればいいだけですよ。普通のキャッシュはちゃんと利いていますから。
Re: (スコア:0)
「そっちのほう」をなんとかしたら遅いだの何だの別問題がわきおこるんでしょうね。
あなたごのみの設計でゼロから直せればそれがベストなのでしょうけど。
Re: (スコア:0)
個人的には、開発中だというrust製エンジンの性能に興味がある。
Re: (スコア:0)
64ビット化を諦めなければ良かったのに…
Re:それはそうと (スコア:2, 参考になる)
正式リリースが1バージョンずつズルズル遅れているのでもうまったく信用できないけど、次のバージョン42から64ビット版がリリースされる予定だよ。ただし
・Flash以外のNPAPIプラグインは使えない(これは仕様)。
・Flashで日本語入力できない(これはサンドボックス化で生じた不具合)。
Re:それはそうと (スコア:1)
・Flash以外のNPAPIプラグインは使えない(これは仕様)。
ですね。
Re:相変わらずブックマーク周りがトチ狂ったまま (スコア:1)
> このページをブックマーク：昔は名前・フォルダ等の編集が出来たのに、最近はブックマーク末尾に追加するだけ。
私の環境でも同じ現象が起きます。「ツリー型タブ」のアドオンをオフにしたら治りました。
Re: (スコア:0)
すべて問題なくできます。
ご自身の環境やアドオンを見直されたほうがよろしいかと。
Re: (スコア:0)
二番目はどういう操作してるのか伝わらなかったので不明ですが
一番目と三番目は出来ますね
一度セーフモードで起動してみては？
たぶんですけどポップアップブロック系かと
Re: (スコア:0)
>このページをブックマーク：昔は名前・フォルダ等の編集が出来たのに、最近はブックマーク末尾に追加するだけ。
メニューから選択して使っていればこれにはまずならないはずです
★をクリックした際に末に付足して、再度クリックで削除と編集ができるようにというのならば仕様です