mikutter

このチケット自体と直接的な関係はなさそうですが、設定画面でパラメータをいじって試した所、followingcontrolのon_periodが倍速で発火しているっぽい事が分かりました（followingsの取得間隔を10分、followersを17分に設定したところ、それぞれ最短の間隔が5分と9分になった）。on_periodがおかしいのか、followingcontrol固有の問題なのかはまだ調べていません。

mikutter側のユーザを取得する処理にも問題がありました(bee6c2f5)。

本筋とは関係がありませんが、変更の規模が小規模なのと、流石に実用に耐えないレベルの影響だったため、以下の問題も修正しました。

しかし単に修正すると、プロフィールタブのフォロイー、フォロワーを開いた時、その数だけ画像のロードが始まります。
そのことによってmikutter 3.5では、以下の問題が発生しました。

• 他の画像がロードされるのが遅くなる #934 (ce9d31ed) によって、同時にダウンロードする画像点数が4枚までとなったため、それが終わるまでほかの画像がロードされなくなります。
• CPU使用率が長時間100%となる 以前もあったが、画像のロードが高速で終わる場合、画像ロード時の負荷が若干上がっているため長時間負荷が高い状態になる

そもそもフォロイー・フォロワーは表示されているぶんだけ画像を読み込めば良くて、ダウンロードのオーバーヘッドが気になるほど大量の画像をロードすることに問題があると考えて、行が表示された瞬間に、その行についてだけアイコンをダウンロードする変更 c2ce3ceb を適用しました。

3.6.0 対応メモ¶

• bee6c2f5 は mikutwitter が Twitter plugin 以下に移動したこと、 Retriever を使っていることから一部修正要
  • テキトーパッチ添付 api_shortcuts.rb.diff
• c2ce3ceb は develop にもそのままマージ可能

上記修正を 3.6.0-develop に当てると、このチケットの問題（フォロー通知が大量に流れる）は修正されているように見えます。

3.6.4にrebaseした新しいブランチを作って、3.6用の手直しを入れました。

それで試してみたところちゃんと動いているようなのですが、テスト用アカウントではフォロー・フォロワー数が少なく検証にならず、toshi_aは凍結されていてフォロー・フォロワーリストが取得できなかったため、そちらで確認してもらいたいです。

この問題は最近はつついさんのほうが見てくれていると思うので、つついさんにレビューお願いします。

（先日から若干運用を変えて、ステータスを「マージ待ち」か「まだダメ」に変えてもらうようにしています。）

topic/916-follow-notification-for-3.6 を checkout してテストしました。
起動直後からフォロー・フォロワーとも表示されているので問題ないと思います。
ちょくちょく error になっているアイコンがありますが、これは twitter側の問題ですかね

master にmergeしました