2004/03/01
HeimdallrというRSS Readerを開発していて思うのですが、RSS周辺のXMLベースの言語であるRSS、ATOM、OPMLは、
バージョンが色々あったり、仕様が曖昧だったりして対応する方は大変です。特にOPML。
仕様書にはほとんど何も書いてないので、同じようで違う様々なOPMLファイルがあり、対応する方は大変です。
しかし、どれもXMLベースであるが故、強力なXML解析ライブラリ(XML Parser)の支援を受けることができ、
対応する方は大変だと言っても楽です。HeimdallrはRSS 0.91/0.92/1.0/2.0、Atom 0.3、OPML 1.0/1.1に対応してはいるのですが、
対応に必要なコードは夫々のバージョンにつきたったの数十行であり、
これだけ様々な形式に対応したにしては楽だったなぁ、という印象がありました。
いやぁ、XMLってほんと便利ですね。
Heimdallrのパフォーマンス向上メモ
Heimdallrのパフォーマンスをさらに向上させていくにはどうすればいいか、というお話です。
私的なメモも兼ねているので内部構造にまで踏み込んでいます。
Heimdallrにどんどんサイト(RSSファイルのURL)を登録していくと、
パフォーマンス面で3点ほど問題がでてきます。
- 起動が遅くなります。Heimdallrは、終了時に全ての記事のタイトルと概要をファイルに保存しておき、
起動時にはこのファイルを読み込んですぐに表示します。これにより、RSSファイルをダウンロードする前に
(内容は古いにしろ)記事のタイトルと概要を表示することができるわけです。
ところが、サイトの数が多くなると、「全ての記事のタイトルと概要を保存したファイル」が大きくなり、
読み込むのも処理するのも大変です。Pentium4 3GHzを搭載したPCで、記事の数が約3000件のとき、Heimdallrを起動すると、
約10秒ほどかかります。これは辛いですね。
- キーワード検索が遅くなります。Heimdallrは、全ての記事のタイトルと概要に対し、キーワードに一致していないか検索を行うのですが、
これをGUIが動作しているスレッドと同じスレッドで行っているので、キーワード検索を行うとき、Heimdallrが短時間操作不能になります。
Pentium4 3GHzを搭載したPCで、記事の数が約3000件のとき、2-3秒操作不能になるようです。環境によっては10秒を超えるでしょう。
これは辛いですね。
- ダウンロードが遅くなります。手動で最新の情報に更新する操作を行った後、
実際に最新の情報が表示されるまで、Pentium4 3GHzを搭載したPCで、記事の数が約3000件のとき、なんと70秒もかかってしまいました
(これはPCのスペックよりも回線速度の方が影響を与えているとは思いますが、目安ということでPCのスペックを書いておきます）。
新しい記事をすぐ見たい！と思っているときにこれでは辛いですね。
さて、次はどうやってこれらの問題を解決していくか、というお話です。
ユーザが問題があることに気が付かないようにできれば良いので、そこらへんを含めて考えて見ます。
まずは妥協可能なポイントを考えて見ます。
- メモリは大量に使って良い。メモリを大量に使うとメモリの少ない環境ではスワップが発生し、
あらゆる操作が遅くなって大変なことになりますが、仕方が無いものとします。
数百MBのメモリを使うのはさすがにまずいですが、100MBに達しなければ許容するものとします。
- 終了に時間がかかっても良い。アプリケーションというのは起動時間は気になることが多いですが、
終了時間についてはあまり気にされません。実際気になりません。気にされる方もいらっしゃるかもしれませんが、
そこは仕方が無いものとします。
起動が遅くなる問題は、次のような解決策が考えられます。
- ユーザに我慢してもらう。Heimdallrは常時起動して使うアプリケーションなので、
起動するのはPCを起動したときだけです。よって我慢してもらうというのもありです。
- 記事のタイトルと概要を別ファイルにする。記事の概要は、タイトルに比べてだいぶ分量が多いため、
読み込むのに時間がかかると想定されます。よって記事のタイトルだけ読み込んだらタイトルだけ表示し、
概要は別スレッドでゆっくり読み込む、という方法は有効だと思われます。
- 表示されていない記事の概要は記録しない。結構良いアイデアではないかと思います。起動直後にウィンドウの大きさを大きくされてしまうとちょっと面倒ですが、ほとんどの場合ユーザにはばれずに済むでしょう。
しかし起動シーケンスに手を加えると言うのは結構大変です。特に並列処理なんてやると大変です。さてどうしたものでしょうか。
キーワード検索が遅くなる問題は、次のような解決策が考えられます。
- キーワード検索をバックグラウンドで実行する。バックグラウンドで実行すると、
メインスレッドとのやりとりにオーバーヘッドがあるため、検索の時間は多少増えます。
でもGUIに影響が無いのでユーザは気が付かないはずです。
キーワード検索アルゴリズム自体はもう最適化済でこれ以上の最適化方法が思いつきません。うーむ。
ダウンロードが遅くなる問題は、次のような解決策が考えられます。
- ユーザに我慢してもらう。ダウンロードはGUIとは異なるスレッドで密かに行っているので、
ダウンロード中でも記事の閲覧などは行えます。気になるのは起動直後の更新と手動更新のときでしょうが、それさえ我慢してもらえば
あとは気にならないはずです。
- ダウンロードを並列に行う。RSSやATOMは、サーバが毎回CGIで生成している場合もあります。
分割ダウンロードを行うことにより、サーバ側の処理時間を実質無くすことができますので、
そこそこ高速化はできそうな気もします。
他にもダウンロード時間を予測して表示するなど色々手はありそうですねー。
何故、記事が3000件のような場合のパフォーマンス問題を気にしているかと言いますと、
Heimdallrはバージョン1.02からRSSファイルと同じようにOPMLファイルを扱えるようになる予定です（OPMLによるインポート／エクスポート機能とは異なるものです）。
つまり、一つのサイトのURLとしてOPMLファイルのURLを登録すると、OPMLファイルをダウンロードし、
その中にURLが記述されているRSSファイルを全てダウンロードし、
全ての記事のキーワード検索などを行い、適当に絞り込んでビューに表示してくれます。
この機能は便利なことは便利なのですが、ひょいひょいOPMLファイルのURLを登録していくと、
記事の数が100件単位で増えていき、3000件などあっという間に越してしまいます。
というわけで、記事の数が3000を超える事は「良くある事」になってしまうわけです。
そして各種パフォーマンス問題が発生し、「なんじゃこりゃー」となるわけです。
Heimdallrは、以前の日記にあるように、軽快に動作することが売りの一つなので、こういうパフォーマンス問題はちょっと許しがたいものがあります。
バージョン1.02までにこれらのパフォーマンス問題を解決できる見込みはないので、
OPML登録機能をOFFにしてしまおうかとも思いましたが、
せっかく実装した機能をOFFにするのももったいないので、
ドキュメントには書かない隠し機能としておく予定です。
