mikutter

症状的に、メモリリークの類だと思うので #198 と重複してると思います。そうなら、このチケットは却下ではなく #198 の子チケットにしようと思いますがどうでしょう　(メモリを使う問題は多くの問題が絡んでいるので統合するのは望ましくない)。
先行チケットはメモリではなくオブジェクト数基準のデータしか上げてませんが、見ていただければわかる通り原因はタイムライン周りにあることは明白で、報告いただいたデータとこれまでの情報を総合すると、なかでもツイートがスクロールアウトしたときのオブジェクトの破棄には少なくとも問題がありそうです。
参考までに、Ruby, RubyGTK, GTKのバージョンを教えて下さい。

子チケットの件，了解です．

ツイートがスクロールアウトしたときの動作ですが，この状態で数時間放置したあとに同じことをした結果，メモリ使用量は増加しませんでした．
（ずっとスクロール操作を続けた場合にどうなるかはまだ未検証です）
ガベージコレクション自体は動いていて，ガベージコレクトされた領域についてRuby(Gtk)が正しく把握していないか，
解放したメモリ領域が不連続もしくはGTK等に予約された状態になっていてOSに返されていないのではないか，とも考えました．憶測に過ぎませんが．

Ruby，RubyGTK，GTKのバージョンは以下の通りです．
----
ruby-1.9.3p125
ruby-gtk2-1.1.3
gtk+-3.2.4-r1
----

メモリ使用量という観点から言えば、GCされたにもかかわらず一度拡大したスタックやヒープが縮小されてなくて、同様の症状が起こっているにもかかわらず、数字として顕在化していないという考え方もできます。一度 #198 の各コミットでどのような対策をしたか、どのような問題がわかったかをある程度書いているので見てみてください。放置しているのではなく、結果は出せてないけれど定期的に時間を割いて調査はしているが分からない、というのが現状です。
今は0.2のリリースに集中してるので見れませんが、予てからRubyGTKのバグもしくは使い方が誤っているのが原因と見ていて、根本的に解決するならmikutterではなくそれらのソースにコミットする必要があるかもしれないと考えていたし、もしそうなら(開発を続ける限り調査は続けるが)俺には修正できないと思っている、ということは伝えておきます。
いずれにせよ、 #198 を中心にして情報共有はしていきたいとは思ってます。