Thousandの高速化

今までThousandは基本的なところを作ってきたので、あまり高速化に注意が払われていない実装になっていますが、そろそろ出来るところからちょこちょこやってみようと思いますよ。何が出来るだろう。

スレッドリストのキャッシュ

今のThousandは（ブラウザウインドウを一つしか開いていなければ）表示しているスレッドリストのみをメモリ上に保持しています。ブックマークリストやスレッド履歴などを除けば。これがどういうことかと言えば、別の板を選択したときには、別の板が新たにディスクから読み込まれ、また今まで開いていた板がディスクに保存される、という処理が実際の板の表示前に多分行われます。スレッドリストをいくつかキャッシュしておく事で、頻繁に見る板についてはこれらのディスクアクセスやなんかの処理をしなくて済み、レスポンスが向上するでしょう。ちょっとだけ。

ディスクへの保存を別スレッドで行う

スレッドリストの解放＝ディスクへの保存が多少時間を食い、レスポンスを低下させるのだとしたら、それを別スレッドで行えばランループはそのまま動くでしょう。スレッドリストをキャッシュするだけでは保存処理が起こらないものが発生してしまうので、どこかのタイミングでこの保存処理をしなければなりません。

スレッドリストのプリフェッチ

上記のスレッドリストキャッシュは起動直後には空なので、板を見る際にはディスクから読み込む処理がどうしても必要になります。しかし、ソースリストに登録してある板を起動後に別スレッドで読み込んでキャッシュに追加していくなどすれば、すぐにキャッシュの効果が現れるでしょう。

スレッドのプリフェッチ

スレッドも少なくない量のデータをディスクから読み込むので、開くのに多少時間がかかります。なんとかしてユーザーが次に開きそうなスレッドを推定できれば、レスポンスが向上するでしょう。「次の未読スレッド」などは、これから開くスレッドを特定するのにいいかもしれません。

スレッドの遅延レンダリング

スレッドを表示するのにはWebKitを使っていますが、1000もレスがあるスレッドを全て表示するとなるとさすがのWebKitもちょっともたつくような気がします。DHTMLを使って、表示されない範囲については後から追加していけばもっと一瞬で表示が終わるのではないでしょうか。

TableViewへの表示にBindingではなくDataSourceを使う

DataSourceなら実際に表示する範囲のデータだけを提供することができます。…Thousandにはあまり関係ないかも。

DNSプリフェッチ

冗談です。Google Chromeがやってるテクニックですが、Thousandは2chブラウザなのでアクセスするサーバーはほぼ決まっていますから、効果は無いに等しいでしょう。

実装するには？

プログラミングを正式に習ってきたわけではないのでこういう高速化テクニックは素人で、まあ考えるのは面白かったりするのですが、これらの手法はretainCountが把握し辛くなったり、マルチスレッドに起因するバグの危険性を持っていたりとそれなりに手間がかかるものです。実装にはまだまだ時間がかかりそうです。