ライブラリ性能改善中
非難の的であったNNDDのライブラリのもっさり具合。
v1.25.0ではこれの改善を目指しています。
実現方式
ライブラリの何が重いかというと、指定されたディレクトリ内の項目を、一覧に表示する処理が重いのです。（特に、表示するムービー一覧を探すのが。）
実測
探索対象の動画は250ムービー。ディレクトリ内には動画ファイル以外にもコメント、投稿者コメント、サムネイル情報、サムネイル画像、市場情報が存在します。（存在しない物もあります。）そのため、実際のディレクトリ内の項目数は約1,100項目。また、library.xmlに登録されている動画は750ムービー。
上記条件で実測してみました。*1
| 方式 | かかった時間 | 探索対象項目数 |
|---|---|---|
| 従来方式 | 550ms | 1,100ファイル |
| 新方式 | 120ms | 750ムービー |
また、かかった時間のうち、100msは一覧表示用オブジェクトの構築処理にかかっています。なので、純粋にファイルの探索にかかった時間は、
| 方式 | かかった時間...(1) | (1)-構築処理時間...(2) |
|---|---|---|
| 従来方式 | 550ms | 450ms |
| 新方式 | 120ms | 20ms |
早くならないパターン
探索対象ディレクトリ内のムービーの件数よりも、library.xmlに登録されているムービーが圧倒的に多い場合、上記ほどの速度向上が期待できない（むしろ遅くなる）場合があります。
上記各方式における各ファイルごとの処理時間は、
- 従来方式：550ms / 1,100項目 = 0.4ms/項目*4
- 新方式：120ms / 750項目 = 0.16ms/項目
例えば、10,000件以上のムービーを100以上のフォルダに分割して保存しているようなパターンです。各フォルダには100個のムービーを含む400個のファイルが存在するとしましょう。
この場合、従来方式では400個のファイルを比較するだけですみますが、新方式だと10,000個のファイルを比較する必要があります。それぞれの項目選択から表示完了までの時間は、
- 従来方式：400項目 * 0.4ms + 100ms = 160ms + 100ms = 260ms = 0.26s
- 新方式：10,000項目 * 0.16ms + 100ms = 1,600ms + 100ms = 1,700ms = 1.7s
このパターンだと新方式の方が従来方式よりも6.5倍遅くなります。
メモリ中に保持するlibrary.xmlに登録済み動画を線形に保持するのではなく、ディレクトリ構造と同じように階層で管理すれば事態は改善される気がしますが。さて、自分で2分木的なものを実装するのか・・・？
そんなわけで、次期バージョンのリリースはもう少し先になりそうです。
