操作
最適化 #927
完了
バグ #925: mikutterがメモリを大量に消費することがある
一度も表示されたことのないGtk::TimeLineに追加されたiterがGCされない
開始日:
2016-11-09
期日:
進捗率:
0%
プラグイン名:
説明
#925の
>>> GC.start;ObjectSpace.each_object(Gtk::TimeLine).reject{|t| t.destroyed?}.map(&:size).sort.reverse
[3959, 1243, 1041, 383, 206, 200, 200, 200, 200, 187, 182, 119, 117, 108, 97, 84, 76, 73, 60, 60, 59, 59, 58, 56, 52, 51, 44, 41, 41, 40, 40, 39, 38, 37, 35, 35, 34, 34, 29, 28, 27, 27, 27, 27, 25, 24, 24, 23, 23, 23, 22, 22, 21, 21, 20, 20, 14, 13, 12, 10, 8, 8, 7, 6, 5, 5, 5, 5, 4, 3, 3, 3, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
に関して、起動時から1回も表示されていないGtk::TimeLineにMessageを追加すると、@remover_queueに追加されないためiterがずっと残り続けます。
ファイル
toshi_a 初音 さんが約8年前に更新
たしかにこれは良くないですね。こっちでも実際の効果を測定したいと思うんですが、なんか測定したりしました？
多分、その出力の最大が全部200になるとかですよね
toshi_a 初音 さんが約8年前に更新
- ファイル mikutter-memory-b1a15108.png mikutter-memory-b1a15108.png を追加
- ファイル mikutter-memory-e4984337.png mikutter-memory-e4984337.png を追加
全く同じ時間帯に、同時に e4984337 適用前後のmikutterを起動して様子を見てみました。
計測は、ホームタイムラインを表示しながら、抽出タブ（データソース: 全てのメッセージ・条件: 指定なし）をバックグラウンドに開いて、できるだけUIを触らないようにして行いました。
なんか突然増えている謎の時間帯がありますが、Gtk::TreeIterとGdk::MiraclePainterのリークが改善されていて、数が一番多いStringも一定のラインで増加が止まっているように見えます。
一方で、実メモリは550MBと549MB消費していて、ほとんど差がないです。 #925 で言われているように、少量のPixbufなどのオブジェクトの参照が残っていて、メモリを多く消費しているのかも。
ともかくこの修正によってかなり改善することがわかったのでmergeしようと思います。
操作