blogに引っ越しました。実はsoramame_bsclにアイコン作るように去年のはじめにお願いしてて、半年放置されたからヤツの落書きを勝手にアイコンにしてただけだったんですwwwwやっとだよwwwwウェブページのファビコンにもしたよ!やったねたえちゃん!よくなかったことキャッシュがスレッドセーフじゃなかったギャアアアアアアアwwwww俺SUGEEEEEEEEEEwwwwwwww特定条件を満たすつぶやきをふぁぼると落ちるひでぇぇぇぇwwwwwwwリスト取得するときにたまに落ちてたウワアアアアアアアアアアwwwwwwwもうかくのめんどくせえよおおおおおwwwwww0.0.2.10以前を使ってる人は、ここのところ全く機能追加できてないお陰で安定性上がってるっぽいので是非バージョンアップしましょう。Faultが発生していた→rubyか周辺ライブラリのバグを踏んでいたようnotifyのリツイート通知の時に、原文が2回表示されていた最適化アイコン画像プリフェッチ殆ど何も変更できてないわけだけれど、これが0.0.3.0になるんじゃないかな、落ちないので。まあリリースして1日以内にクラッシュするような不具合が見つかるというのを10週連続でやってるんだけどね!あとレンダリング高速化しようとしてやっぱりやめました。時間をかけて大規模なのをやります今度。0.0.2.10リリースしました。ことがあるうけるヾ(@⌒ー⌒@)ノまじこれだけあと少しパフォーマンスを上げようとして、ああ、今回もだめだったよ。根本的な解決をしていきたい。mikutterのコードも当社比リファクタリングが進みきれいになったので、マルチスレッドでGtkのレンダリングをしても死なない気がしてきた!ちょっと頑張って見るかな。10:252011年3月2日水曜日streamingプラグインの最適化streamingプラグインはuserstreamを実現するためだけのプラグイン。(core/addon/streaming.rb)UserStreamは大量のデータが落ちてくることがしばしばあり、フォローが多いと秒間に数個からヘタをすると数十個のイベントが落ちてくることもあるかも知れない。(ここでつぶやきではなくイベントと言ってるのは、フォロー関係の変更やDM、favなども落ちてくるので)mikutterでは、正確にはわからないが、まあフォローが1000を超えていたら絶対に動かないだろう。これは、流速が処理速度を超えるから。いう極端に速い環境を切り捨てるのは仕方ないにせよ、全員が定期的に呟いている訳でもないので毎週火曜夜に流速が極端に速くなるということもあるかもしれない。できるだけ対策をしてみようと思った。これの33行目くらいから変な魔術を使ってる。endevent_favoriteメソッドがfavられた時に呼ばれる。こいつが実際のイベントをよんでいるんだけど、いちいちdefine_eventを使って定義している。このdefine_eventで定義されるevent_favoriteは、Queueに引数をそのまま積んでおしまい。実際には、定義されたと同時に作られた別のスレッドがイベントの処理をする。これによって、イベント発行にだらだらと時間を使ったりせず、効率的にイベントを発行できるというわけ。・・・ではなくて、見ていただければわかるとおり、1つキューを消化するごとにsleep(1)を実行しています。同時に100favされたとすると、普通の実装だと死ぬほどイベントを発行して、効果音がけたたましく鳴り響いてTLの更新がしばらくおっつかなくなるんですが、この実装によって、最初の1favは即時、残りは99秒かけて1秒間に1つづつイベントが実行される。これによってイベントの実行が遅れる場合が出てくるが、乱発されない限り目立った遅延は起こらない。1つづつしかイベントが発生しないので、処理もすぐに終わるからたいした負荷もかからない。フォローなどについても同様。唯一の例外はつぶやき受信関連。これだけはちょっと違って(詳しくはソースみてくださいそんなにありがたいものじゃないが)、つぶやき関連のイベントは、1回のイベントにいくつでもつぶやきを持たせることができる。1回のループで、キューに溜っているイベントを全て取り出して、一気にイベントを発生させる。これによって、1秒間に大量のつぶやきを処理する可能性があるけれど、実はイベントの発行って結構非効率なので、10イベンtの発行するよりも1イベントで10ツイートを処理するほうがはるかに経済的。いうかそんなのが頻繁に起こるならどのみちmikutterつかえない重要なのは、同じイベントは1秒に1回しか発生しないようになった、ということ。どんな速度でイベントが発生しても、ここでイベントの流量が制限されるようになるわけ。これによって、例えば1分間に100favとかされたときにフリーズすることがなくなりました。今後の展望(というか実験中のこと)としては、GUIイベントを処理している時など、今やったらユーザの操作に影響が出るぞっていう時にはイベントの発行をさらに1秒遅らせるというの。ウィンドウが完全に応答なしになってるのに次々イベントほりこんでもしゃーないでしょ、という話。TL速い時に起動が数秒遅くなってるんですが、これは起動直後にウィンドウに夥しい量のつぶやきが放り込まれて固まってる間にたくさんイベントが発生しているからに他ならないんですよ。本当に重くしてる原因は他にあると思うので、そっちを潰すのが先かなぁとも。動きが良いのは良いことです。