内容

前提として、現在のVVMのインターフェイスとしては次の二段階に分かれています。

1. VVMをZIPとして開き、manifest.jsonとmetas.jsonを読む。開いたZIPは閉じる。
2. VVMをもう一度ZIPとして開き、*.{onnx,bin}を読む。

さて、ZIPの読み方にはZIPをメモリに全部載せてから解凍する方法と、ZIPをファイルとして読みながら解凍していく方法があると思います。async_zipのAPIの構造にならってこれらをそれぞれ"mem版"と"seek版"と呼ぶことにします。
（"stream"版という概念もあるのですが、ここでは一旦考えないことにします）

最新（v0.0.17および現時点でのmainブランチ）のasync_zipのseek版はtokio::fsを通すと大きなファイルエントリに対しては到底現実的ではない速度であるため、VOICEVOX COREでは現在すべてmem版を使うようになっています。しかしtokio::fsではなくasync-fsというライブラリを介すると速度が著しく改善され、zipクレートと比べても劣らない、どころか上回ることがわかりました。

ちなみに、async-fsを使う前提のもとsample.vvmの1.(JSON二つ)と2.(ONNX三つ)それぞれに対して{zip, async_zip} × {mem版, seek版}の四通りのベンチを取ったところ、1.と2.どちらも「async_zipのseek版」が最速になりました。1.は252.72 μs、2.は185.90 msでした。

以上のことから #746 をやる際1.と2.の両方を、async-fsを介した上でasync_zipのseek版に戻してしまうことを提案します。メリットは以下の通りです。

Pros 良くなる点

• メモリ消費の軽減の可能性。こちらに関しては計測していないが、改善はされても悪化はしないはず？
  • もし軽減されるのなら、ENGINEにとってもメリット。 [release-0.15] .onnx/.binファイルの読み込みを遅延させる #768 の続きということにもできる？
  • 軽減といってもqwertyさんの元々の実装がseek版だったのですが
• VoiceModelの実装を統合する #746 を円滑に行える
  • async-fsはグローバルに保持されるスレッドプールを使うようになっており、「ランタイムレス」で動く。そのためブロッキング版コード上でそのままawaitできる
• VoiceModelをVoiceModelFileにし、ファイルディスクリプタを保持する #829 も円滑に行える

Cons 悪くなる点

無いはず。

実現方法

#746 と一緒に実装する。

VOICEVOXのバージョン

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他