アカウント名:
パスワード:
Firefoxそのものが元々メモリ食いなわけで、個人的にはそっちのほうを先になんとかしてほしいのですが。これについてはいっそのこと一から設計し直すとかしなきゃダメなのかな?
閉じたウインドウとかタブで使っていたメモリをきちんと回収したらいいと思うんですけどね
malloc/free ではすぐには回収されないからね独自のメモリプール使っても、肥大化は抑えられても解放は結局同じだしChrome みたくプロセスごと Kill するのが解放するには一番いいトータルのメモリ使用量は一気に増えるだろうけど……
# 昔のメモリ解放ソフトみたく、瞬間的に大量に確保して仮想メモリに追いやったらどうだろう# 仮想メモリ 0 にしてる私の環境では死ぬだろうけど
malloc/freeはアプリ内のプールへは即座に返却される。一方システムにはいくら待っても返却される保証はない。独自のメモリ管理をしたうえでOSのメモリ管理API叩きましょう。
# 昔のメモリ解放ソフトみたく、瞬間的に大量に確保して仮想メモリに追いやったらどうだろうFxには以前ウィンドウ最小化でワーキングセットが縮小してそういう効果が得られる的なTipsがあったような。つか仮想メモリに追いやってもメモリ(仮想メモリ)は開放されないからバカ食いの問題自体は解決しないぞ？
メモリの議論はニワカと自称中級者が印象だけでFUDを繰り返しているからもうどうしようもない。
勉強になります
> 独自のメモリ管理をしたうえでOSのメモリ管理API叩きましょう。
メモリ管理 API 直叩きならすぐにシステムに返却されるんですね、知らなかったですただ OS 毎に別コードになるのは面倒ですね
> つか仮想メモリに追いやってもメモリ(仮想メモリ)は開放されないからバカ食いの問題自体は解決しないぞ？
以前携わっていたアプリが、大量にメモリを喰った後大幅にメモリ使用量が減るという現象があったので、強制 GC のようにシステムへの回収をキックできるのではと思いました。ただ根拠はないです。
Firefoxはjemallocというmallocの独自実装を使っています。https://github.com/jemalloc/jemalloc [github.com]http://mxr.mozilla.org/mozilla-central/source/memory/jemalloc/ [mozilla.org]
memory fragmentationとかでググってみてください。
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]
bfcacheが気に入らないなら、network.http.use-cacheをfalseにすればいいだけですよ。普通のキャッシュはちゃんと利いていますから。
「そっちのほう」をなんとかしたら遅いだの何だの別問題がわきおこるんでしょうね。あなたごのみの設計でゼロから直せればそれがベストなのでしょうけど。
個人的には、開発中だというrust製エンジンの性能に興味がある。
64ビット化を諦めなければ良かったのに…
正式リリースが1バージョンずつズルズル遅れているのでもうまったく信用できないけど、次のバージョン42から64ビット版がリリースされる予定だよ。ただし・Flash以外のNPAPIプラグインは使えない(これは仕様)。・Flashで日本語入力できない(これはサンドボックス化で生じた不具合)。
・Flash以外のNPAPIプラグインは使えない(これは仕様)。
ですね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
それはそうと (スコア: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プラグインは使えない(これは仕様)。
ですね。