async_zipをv0.0.16に上げる

[qryxip]

内容

#746 の準備として、async_zipをアップデートします。

関連 Issue

その他

[qryxip]

draftなのは、デバッグビルドとリリースビルドの両方でパフォーマンスが死ぬほど悪化しているからです。pytestが1秒から40秒超になった…

[qryxip]

async_zip v0.0.16

`manifest.json`: 118.411µs
`metas.json`: 112.239µs
`decode.onnx`: 46.452658156s
`predict_intonation.onnx`: 91.230371ms
`predict_duration.onnx`: 119.468319ms

async_zip v0.0.11

[INFO] voicevox_core.voice_model.tokio: `manifest.json`: 88.805µs
[INFO] voicevox_core.voice_model.tokio: `metas.json`: 111.588µs
[INFO] voicevox_core.voice_model.tokio: `predict_intonation.onnx`: 6.197363ms
[INFO] voicevox_core.voice_model.tokio: `predict_duration.onnx`: 6.660366ms
[INFO] voicevox_core.voice_model.tokio: `decode.onnx`: 354.287178ms

[qryxip]

単純にdeflateがめちゃくちゃ遅くなっているっぽい。tokio_util::compat越しにfutures-liteで動くようになったのが駄目としか思えない...

[qryxip]

やっぱそうだ。zipファイルを全部メモリに載せてasync_zip::base::read::mem::ZipFileReaderを使うとdecode.onnxも数百msでちゃんと読める…

[qryxip]

ということでasync_zipのファイルシステムのサポートは使い物にならなくなってしまったことがわかりました。一旦挙動の変更を入れます。VVMのZIPを全部メモリに載せ、そこから個々のファイルを抽出するようにします。

ただmanifestとmetasを読むのにも全部読むことになりますが、他の回避策が思い付きません。

(追記) manifestとmetasを読むときだけtokio_util::compat + seek版を使うとか...?

[qryxip]

あ、Javaが壊れた?
(Javaの依存はロックファイルで固定してなかったはず)

(追記) #748

[Hiroshiba]

LGTM！

そういえばですが、今の0.15あたりのコアはinitializeしただけで1GBほどメモリ消費してることがわかりました。
compatible_engines見た感じ、全部オンメモリにしてるためっぽかったです。
これも同じようなことが起こりそうですが、まあメモリに乗せた後解放してあげれば良いのかなと思いました！
（できるのか精査できてないです）