Misskey & Webテクノロジー最前線

TypeScript 7.0リリース! Misskeyで検証

本連載は分散型マイクロブログ用オープンソースソフトウェアMisskeyの開発に関する紹介と、関連するWeb技術について解説を行っています。

今回は、MisskeyのコードベースでTypeScript 7.0のパフォーマンスを検証します。

TypeScript 7.0

先日、TypeScript 7.0が正式リリースされました。

コンパイラがGoで再実装され、並列処理が活用されるようになったことで大幅にパフォーマンスが向上しています。

Misskeyのコードベースにおいては、ほぼ改修の必要なしに7.0に移行することができました。

ベンチマーク

ベンチマークを紹介します。環境は以下のとおりです。

  • Misskey v2026.7.0
  • TypeScript 6.0.3 / TypeScript 7.0.2
  • Node.js 26.4.0 / pnpm 11.21.0
  • CPU: Intel Core i9-13900K

結果は以下のようになりました。なお、値は5回実行した際の平均で、(純)とあるのはビルドプロセスの起動時間などを省いた純粋なコンパイラ内部の処理時間です。

指標 6.0 7.0 高速化
backend emit 9.587秒 1.903秒 5.04倍
backend type check 8.258秒 1.666秒 4.96倍
backend emit (純) 8.840秒 1.019秒 8.68倍
backend type check (純) 7.520秒 0.883秒 8.52倍

メモリ使用量の比較は以下のとおりです。

指標 6.0 7.0 削減量
backend emit 1,067 MB 1,002 MB 64 MB減 (-6%)
backend type check 993 MB 894 MB 99 MB減 (-10%)

さらに、シングルスレッドモード--singleThreadedでコンパイラを使用すると、より省メモリ化しました。

指標 6.0 7.0 削減量
backend emit 1,067 MB 744 MB 323 MB減 (-30%)
backend type check 993 MB 643 MB 350 MB減 (-35%)

よって、Misskeyのコードベースでも公式発表にある「概ね8〜12倍の高速化」という参考値どおりの結果となり、大幅な高速化が確認できました。

開発中は繰り返しビルドを行いますし、複雑な型の推論も行われるので、ここが高速化する恩恵は大きいです。

さらに、わずかにメモリ使用量が減ったほか、シングルスレッドモードでは30%以上も省メモリ化したことも確認できました。

シングルスレッドの場合、コンパイラの処理時間は筆者の環境では約3倍ほど遅くなりましたが(とはいっても6.0よりは高速)、メモリの制約が厳しいCI上などでは現実的な選択肢になりそうです。

APIについて

TypeScript 7.0では、現時点ではまだコンパイラのAPIの実装が完了しておらず、Vueファイル上での型チェックなど、APIを必要とする一部のユースケースではまだ7に移行できません。

そのためMisskeyでは、バックエンドは7.0、フロントエンドでは6.0を使用しています。

とはいえ7のAPI実装は鋭意開発中という感じなので、完全に移行できる日はそう遠くないと思います。

最近では、Content mappersという仕組みが提案・実装されました。

Content mappersの詳細は割愛しますが、この概念の検討にあたってはまさにVueコンポーネントのような、TypeScriptを別の言語内に埋め込むようなユースケースでの使用が考慮されています。

Content mappers含む公式APIがリリースされ次第、各種ライブラリでも7.0対応が進むものと思われます。

まとめ

今回の検証で、TypeScript 7.0でコンパイラが実際に約9倍高速化し、ビルドプロセスの起動などを含む開発者の実待ち時間では、約5倍の高速化が確認できました。

7.0時点ではAPIが提供されていないため、Vueコンポーネントなど一部のケースではまだ6.0を使う必要があります。

今後APIが実装され、7.0に完全移行できれば更なる開発者体験の向上が期待できます。

また、⁠今まではパフォーマンス上の理由で断念していたコンパイラの機能も、Goになった今なら実現できる可能性がある」とのTypeScript開発者のコメントも以前見かけましたので、今後の進化が楽しみです。

おすすめ記事

記事・ニュース一覧