最適化 #930
完了
バグ #925: mikutterがメモリを大量に消費することがある
Message::MessageUserの代わりに新しくUserを作る
Osamu Koga さんが約8年前に追加.
ほぼ8年前に更新.
説明
#925 の文字列リークは、各ツイートについて1つ作られるMessage::MessageUser
が原因ではないかと思われます。このオブジェクトはUserオブジェクトの他に、TweetにくっついてきたUser情報の生JSON(をparseしたもの)を保持しており、実質Userオブジェクトが2倍以上あるような状況になっています。
>>> GC.start; ObjectSpace.each_object(Message::MessageUser).count
5216
>>> GC.start; ObjectSpace.each_object(User).count - ObjectSpace.each_object(Message::MessageUser).count
4063
元々このクラスは、ユーザがアイコンを変更したりしても過去のアイコンを保持できるようにするためのものでしたが、Retriever::Modelの分離度が上がったので、ユーザの見た目が変わるような変更があったときには新しい
User
を生成してやることで、古いツイートは古い
User
を保持しながら、新しい
User
は
findbyidname
で拾えるようにできます。
Stringが大量にダブる問題は、これである程度解決できるはず。
ファイル
- ステータス を 実装待ち から パッチ適用待ち に変更
このパッチを適用したらメモリ使用量のグラフが劇的に改善しました。下のグラフは、psの結果に出てくるRESを1分毎に記録したものです。
水色はdevelop HEAD( 8ceda65 gtk2 3.0.9)、紫と緑(重なってるけど)はそれぞれこのパッチ適用をした3.0.9と3.1.0の結果です。縦軸はメモリ使用量(単位はKBなので、2*10^6は2GBです)。
あと例のアレ。ニンジャスレイヤーの更新があったことを考えると、かなり落ち着いていると思います。
YUKI.N@aincrad> cat /tmp/strings.txt | sort | uniq -c | sort -k1 -r | head -n30
5964 ja
4283 fit
3285
2985 https
2979 twitter.com
1887 none
1780 C0DEED
1705 000000
1488 333333
1450 /home/osak/app/mikutter/core/lib/uithreadonly.rb:22:in `block (2 levels) in singleton class'
1427 crop
1413 photo
1312 Tokyo
1102 ~>
1080 DDEEF6
980 https://abs.twimg.com/images/themes/theme1/bg.png
980 http://abs.twimg.com/images/themes/theme1/bg.png
966 recent
901 low
892 njslyr
794 1DA1F2
776 mikutter.rb:94:in `<main>'
776 mikutter.rb:65:in `boot!'
776 /home/osak/app/mikutter/core/plugin/gtk/mainloop.rb:10:in `mainloop'
776 /home/osak/app/mikutter/core/plugin/gtk/mainloop.rb:10:in `main'
760 #njslyr
717 /search
711 >=
597 ruby
582 lib
ついでにmemory_profilerの結果も貼っときます(gtk2 3.1.0)
お、すげえ!最近密かにUserがMessageより多くなってて気になってたんだけど(3.5。3.4では未検証)、改善されてるようですね。多分Userの発行数自体が落ち着いたおかげで、メモリリークがマシになったのかな。
コードもMessageUserが消えてベターな感じになったので良いと思います。今日にでもmergeしますね
だんだん伸びて行って、最終的には元とあまり変わらなくなってしまった
Stringの増え方は抑制されたものの、まだ何か漏れてそうですね
- ステータス を パッチ適用待ち から 終了 に変更
他の形式にエクスポート: Atom
PDF