[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/10 01:30 / Filesize : 375 KB / Number-of Response : 954
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

[[[ 2ch ブラウザ JD 9 ]]]



261 名前:作者 mailto:sage [2010/08/31(火) 01:08:44 ID:f+/ZYDsH]
>>252
> レスカウント保持領域(日分)、勢いの集計期間
やっぱりスレ一覧を開いたときに何日か分のデータを保存しているんでしょうかね。
この辺のアルゴリズムに関して詳しい方はいませんか?

壊れた時の差分表示に関してはあっても害は無いと思いますので実装しますが、
今の所は、差分を知りたいときは手動でdatを保存して端末でdiffを取ってみてください。

>>253
お疲れ様です。

>>254
> 画像関連のメモリはどのように確保されてるのでしょうか?
に対する答えは、gtkに画像処理を丸投げしているので良く知らない、です。
ただgtkの画像処理はメモリ食いなので3000枚で1.5Gなら妥当な気もします。

なお私も以前画像を閉じても仮想メモリが開放されない時があるのが気になって調べた事が
あるのですが、カーネルというよりglibcとgtkの問題みたいです。以下、以前走り書き
した時のメモを清書しただけなので内容が古いとか変な箇所があれば指摘して下さい。

まずglibcの問題ですが、glibcのmalloc()は内部でbrk()とmmap()を使い分けてメモリを
確保しています。基本的には確保するメモリサイズがある程度大きいとmmap()を使って
小さい場合はbrk()を使います。問題は mmap()で確保したメモリ領域はfree()すれば
すぐにOSに返されるのに対してbrk()で確保した場合はfree()してもメモリが断片化してると
返されないことで、要するに小さいサイズのmalloc()とfree()を繰り替えしていると、
実際には使っていないのに見た目上はアプリが使っている仮想メモリ領域のサイズが
増えていきます。ただ使ってない領域は実メモリが足りなくなると実メモリから
追い出されるので、精神的には良くありませんが実害は無いのではないか?と思っています。

次にgtkの問題ですが、上に書いたように画像処理は全てgtkに丸投げしているのですが、どうも
gtkは内部でキャッシュ処理か何かをしていて本当に必要がなくなるまでメモリを確保し
続ける?ような感じがします。詳しくソースを追った訳では無いのであくまで勘によるものですが。






[ 続きを読む ] / [ 携帯版 ]

全部読む 前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](;´∀`)<375KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef