続・Turbopack vs Vite 次世代バンドルツールの競争の今

導入

結論ファースト

• 2023年4月23日にVite v4.3がリリースされた。これによってViteのパフォーマンスの改善が実現し、TurbopackとViteの性能差はほぼなく、プロジェクトで導入するのであればViteを導入するのが自然な選択となっている。
• Turbopack側では特にめぼしい動きが見られていない。
• React×TypeScriptのプロジェクトにおいてHMRの実行時間をVite4.2, Vite4.3, Turbopackで比較したところ、ViteとTurbopackでは大きな差が見られ、Viteの方が実行時間が明らかに早く、コンポーネント数の増加に対しても影響が小さかった。

Vite 4.3のパフォーマンス改善

• 「シンプル」「厳密」「正確」なmodule解決ロジックに改善
• 「待ち」が発生するタスクの削減
• HMR時のモジュール探索の効率化
• 並列化
• JavaScriptの最適化

「シンプル」「厳密」「正確」なmodule解決ロジックに改善

• 依存関係のpackage.jsonを解決するために、これまではresolve packageに大きく依存していたが、これには多くの不要なロジックが含まれていた。resolve packageの使用を取りやめて直接nestされた親ディレクトリにあるpackage.jsonをチェックすることでシンプルにした。
• Viteはmoduleを見つけるのにNode.jsのfs APIを呼び出す必要があるが、そのI/Oが高くついた。Vite4.3ではファイルの探索範囲を狭めたり、ある特定のpathについて検索をskipすることでできるだけfsを呼び出す回数を減らした。
• 4.2ではファイルパスがディレクトリの時、モジュールを再帰的に解決していたので、繰り返し不要な計算を行なっていた。4.3では再帰的な解決をフラットにして異なるタイプのpathに適切な解決を行うようにした。このことでfsの呼び出しをキャッシュすることも容易になった。
• キャッシュのキーとして使えるものをファイルの絶対パスだけでなく、ディレクトリパスに拡張することでnode_modules packageのデータの解決の際にボトルネックとなっていた部分を解決した
• 本来異なるresolve contextにあるのに混同してしまっていた、rootのpackage.jsonを見つける処理と、解決したい当該ファイルに最も近いpackage.jsonを見つける処理を分離した。
• fs.realpathSyncはfs.realpathSync.nativeより70倍遅い。これまでWindowsではrealpathSyncしか使えなかったので、Windowsでfs.realpathSync.nativeを呼び出すときにnetwork drive validationを加えることでWindowsでも高速で処理できるように変更した。

「待ち」が発生するタスクの削減

• tsconfigのパース
  Viteサーバーは、tsまたはtsxのプリバンドリング時にtsconfigデータを必要とする。
  Vite 4.2では、サーバーが起動する前にプラグインフックconfigResolvedでtsconfigデータのパースが完了するまで待機する。ページリクエストは、tsconfigのパース待機が必要な場合でも、サーバーが準備完了していない状態でサーバーにアクセスすることがある。
  Vite 4.3では、サーバーが開始する前にtsconfigパースを初期化するが、サーバーは待機しない仕様となった。
• ファイル処理
  Viteには多くのfs呼び出しがあり、一部は同期的に呼び出されている。この同期的なfs呼び出しはメインスレッドをブロックする可能性があったため、Vite 4.3では、これらを非同期に変更した。

HMR時のモジュール探索の効率化

並列化

JavaScriptの最適化

• コールバックによる*yieldの代替
  tsconfigファイルを検索およびパースに用いるtsconfckは以前、*yieldを使用して対象ディレクトリを走査していた。*yieldを用いるデメリットとしてGeneratorオブジェクトを格納するためにより多くのメモリスペースが必要であり、実行時には多くのジェネレータコンテキストの切り替えが発生することが挙げられるが、コアで*yieldをコールバックに置き換えたことで改善した。
• startsWithとendsWithを===で代替する
  Vite 4.2では、ホットURLの先頭と末尾の’/’を確認するためにstartsWithとendsWithを使用していたが、===の方がstartsWithよりも約20%高速で、endsWithは===よりも約60%遅いことが判明したため、代替を行った。
• 正規表現の再生成を回避する
  文字列のマッチングに用いる正規表現を単一のインスタンスとして使用することで再利用可能にした。
• カスタムエラーの生成を中止する
  Vite 4.2で存在した、より良いDXのためにいくつかのカスタムエラーがあるが、パフォーマンスを低下させる可能性のある余分な計算やガベージコレクションを引き起こすことがあったため、Vite 4.3では、いくつかのカスタムエラーの生成を取りやめ、パフォーマンス向上のために元のエラーを直接スローするようになった

パフォーマンスの検証

実験

目的

使用機器

環境

使用技術

測定方法

手順

import fs from 'node:fs'

let imports = ``
let renderCode = ``

for (let i = 0; i < 1000; i++) {
  imports += `import { Comp${i} } from './components/comp${i}.jsx'\n`
  renderCode += `<Comp${i}/>\n`
  fs.writeFileSync(
    `src/components/comp${i}.tsx`,
    `export function Comp${i}() {
    return <div>hello ${i}</div>
  }`
  )
}

const code = `
 ${imports}
export default function App() {
  return <div>
   ${renderCode}
  </div>
}
`

fs.writeFileSync('src/App.tsx', code)

import { watch } from 'node:fs'

watch('src/App.tsx', (e, filename) => {
  const now = new Date();
  console.log(`${now.getSeconds()}s ${now.getMilliseconds()}ms, ${filename}, root`)
})

watch('src/components/comp0.tsx', (e, filename) => {
  const now = new Date();
  console.log(`${now.getSeconds()}s ${now.getMilliseconds()}ms, ${filename},  leaf`)
})

{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "lib": ["DOM", "DOM.Iterable", "ESNext"],
    "allowJs": false,
    "skipLibCheck": true,
    "esModuleInterop": false,
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "module": "ESNext",
    "moduleResolution": "Node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react-jsx"
  },
  "include": ["src"],
  "references": [{ "path": "./tsconfig.node.json" }]
}こ

import { FunctionComponent } from "react"
const Comp0: FunctionComponent = () => {
const now = new Date();
const filename = 'comp0.tsx';
return<div>leaf: {`${now.getSeconds()}s ${now.getMilliseconds()}ms, ${filename}, leaf`} 1</div>
}
export default Comp0

const　now = newDate();
const　filename = 'App.tsx';

root: ${`${now.getSeconds()}s ${now.getMilliseconds()}ms, ${filename}`}

測定結果

結果から導ける結論

• leaf componentのHMR時間については、ViteがTurbopackよりも大きく差をつけて速いという結果になった。これは使用感とも概ね一致した。
• Turbopackはモジュール数が増加するごとに、それに比例するように実行時間が長くなっている。体感的にもモジュール数が増えるごとに、ファイルの変更から描画まで相当なタイムラグを感じた。
• Viteはモジュール数の増加に対してHMRの実行時間が大きく変化することはなかった。

検証の課題

• Evan You氏の実験や、公式に発表されているVite4.3の性能調査と異なり、今回はReact×TypeScriptのプロジェクトで開発を進めることを想定している。そのため、純粋なVite, Turbopackの性能と異なる要因が混在している可能性を考えなければならない。（ただし、これが双方の比較の公平性を毀損しているわけではないと考える。両者のプロジェクトの使用技術・構成がほぼ同一だからだ。）特にVite4.2とVite4.3の比較結果については、TypeScriptからJavaScriptに変換する処理や、その他、今回の環境的な要因がより大きい誤差を生じさせ、見かけの性能差を逆転させてしまったのではないかという仮説について考えなければならないだろう。
• Viteの方は、各実行において、実行時間に大きなばらつきがあった。同じ条件で500msかかる時と、約150msで実行できる場合などがあったため、外れ値の影響を大きく受けてしまっていると考えられる。その一方でTurbopackの方は各実行において実行時間が大きくばらつくということは起きなかった。Viteにおける実行時間のばらつきの大きさの原因が何なのかは今後の調査課題としたい。

まとめ

参考資料

最後に