Closed qryxip closed 6 months ago
draftなのは、デバッグビルドとリリースビルドの両方でパフォーマンスが死ぬほど悪化しているからです。pytestが1秒から40秒超になった…
`manifest.json`: 118.411µs
`metas.json`: 112.239µs
`decode.onnx`: 46.452658156s
`predict_intonation.onnx`: 91.230371ms
`predict_duration.onnx`: 119.468319ms
[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
単純にdeflateがめちゃくちゃ遅くなっているっぽい。tokio_util::compat
越しにfutures-liteで動くようになったのが駄目としか思えない...
やっぱそうだ。zipファイルを全部メモリに載せてasync_zip::base::read::mem::ZipFileReader
を使うとdecode.onnxも数百msでちゃんと読める…
ということでasync_zipのファイルシステムのサポートは使い物にならなくなってしまったことがわかりました。一旦挙動の変更を入れます。VVMのZIPを全部メモリに載せ、そこから個々のファイルを抽出するようにします。
ただmanifestとmetasを読むのにも全部読むことになりますが、他の回避策が思い付きません。
(追記) manifestとmetasを読むときだけtokio_util::compat
+ seek版を使うとか...?
あ、Javaが壊れた? (Javaの依存はロックファイルで固定してなかったはず)
(追記) #748
内容
746 の準備として、async_zipをアップデートします。
関連 Issue
その他