Closed qryxip closed 2 months ago
Hiroshiba
commented
2 months ago issue作成ありがとうございます！！ デメリットなさそうであれば問題ないと思います！
とはいえ流石にメモリよりファイル読み込みのが早いのはちょっと違和感があります。 もしかしたらファイルシステムキャッシュが作られてるからかも？
でもここからファイル読み込みの遅延が入ったとしても全然問題ない範囲だと思います！ メモリに載せない選択に賛成です！
qryxip
commented
2 months ago とはいえ流石にメモリよりファイル読み込みのが早いのはちょっと違和感があります。 もしかしたらファイルシステムキャッシュが作られてるからかも？
あ、mem版についてはZIPファイルを一度ファイルシステムから読み込むところから計測に入れています。 （何故なら現実のユースケースがそうなので）
seek版はZIPファイルの読み込みとその解凍を同時進行するようなイメージです。
Hiroshiba
commented
2 months ago あ、なるほどです！問題なさそう！
内容
前提として、現在のVVMのインターフェイスとしては次の二段階に分かれています。
さて、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 良くなる点
746 を円滑に行える
829 も円滑に行える
Cons 悪くなる点
無いはず。
実現方法
746 と一緒に実装する。
VOICEVOXのバージョン
OSの種類/ディストリ/バージョン
その他