Vitest5.0は何が速くなったのか

Transcript

1. 2026年9月 Vitest 5.0 は何が速くなったのか 全5回 ① 性能改善 赤神 青空
2. ▪4.1.10 とどれくらい速くなったか 5.0 の比較（Node 24 / 3回の中央値） −53% deps-heavy 1.59s → 0.74s（vmThreads） 今ココ 性能 −25% long-haul 5.43s → 4.06s（vmForks + happy-dom） −19% enterprise-monolith 7.24s → 5.83s（1,280モジュール） 2/7
3. ▪全部が速くなるわけではない 伸びる条件・伸びない条件 大きく効くのはvm系プール・Browser Mode・大規模なisolate実行。 効くところ vmThreads / vmForks Browser Mode（Chromium） モジュール数の多いisolate実行 ほぼ横ばいのところ forks + jsdom + isolation は 4.1 と±3%以内 環境セットアップが時間を支配している条件 測定用のリファレンスアプリ群は vitest-dev/benchmarks で公開されている 今ココ 性能 3/7
4. ▪効きの大きい2つを図で 何をして速くなったのか ① Vite 設定を変えない projects が Vite サーバーを共有する Vitest . project: unit Vite サーバー Vitest . project: unit project: e e Vite サーバー project: e e project: node Vite サーバー project: node 共通ファイルを 3 回変換する Vite サーバー 1 つを共有 共通ファイルの変換は 1 回だけ ② fsModuleCache が安定化（変換結果をディスクに残す） 1 回⽬ テスト実⾏ 変換 2 回⽬以降‧別プロセス テスト実⾏ ディスクに保存 保存済みの変換結果を再利⽤ 変換をやり直さない sharedViteServer による Vite サーバー共有と、fsModuleCache の永続化 今ココ 性能 4/7
5. ▪図にしなかったもの そのほかの高速化 メインプロセスとワーカー間の往復を削減。変換済みのモジュールは1往復で渡る プールとブラウザ vm系はコンパイル済みコードを再利用し、 require(esm) にも対応 Browser Modeは自身のランタイムをprebundleし、セッションを適応的に開く 周辺 Vitestが自身の依存をバンドルし、インストールが軽くなった カバレッジは v8 が有界メモリでマージ、istanbul は @vitest/istanbuljs へ 今ココ 性能 5/7
6. ▪レポーターの内訳表示と、新コマンド 遅い理由を数字で出す vitest doctor 所要時間の内訳が割合で出るようになった。設定で速くできそうなときはヒントも出る。 text Duration 3.76s (environment 79%, import 13%, transform 6%, tests 1%, setup 1%) bash vitest doctor 今ココ 性能 # 別の設定でテストを走らせ、速くなる設定を提案する 6/7
7. ▪ 第1回のまとめ 効くのはvm系プール・Browser Mode・大規模なisolate実行。 大きいところ deps-heavy の vmThreads で 1.59s → 0.74s。 横ばいのところ forks + jsdom + isolation は 4.1 と±3%以内。 まず自分の設定がどの条件に当てはまるかを見るところから。 今ココ おわりに 7/7