型チェック速度改善奮闘記⌛

型チェック速度改善奮闘記⌛ 2024/11/16 TSKaigi Kansai Kenta TSUNEMI

Kenta TSUNEMI @tocomi 🏢テックタッチ株式会社 󰞵フロントエンドエンジニア 🏡 東京都在住栃⽊県出⾝趣味 🏇
競⾺ ⚾ 野球観戦(ヤクルトファン) 🃏 ポーカー 🎮 ゲーム⾃⼰紹介

今⽇は Typescript の型チェックの速度改善に取り組んだ話をします！結果について触れつつ、特に調査のプロセスに重点を置いて話そうと思います💪 この発表が、みなさんが Typescript の速度改善に取り組むきっかけや⼿助けになれば嬉しいです😌 今⽇の発表について

⽬次 🔖 1. 背景 2. 改善活動の結果 3. 調査プロセス

Nx を使ったモノレポで管理 3 つのアプリケーションと、100 近くのモジュールが存在している⚙ アプリケーションからモジュール、およびモジュール同⼠の依存があるプロダクトの成⻑と共にモジュールの数が絶賛増加中🔥
アプリケーションの概観 ※画像はイメージです

プロダクトが成⻑していくにつれて、Typescript の型チェックに時間がかかるという声がチーム内で上がってくるように、、ただ普段の開発業務に追われていて対応が後回しになっていた🥲 VSCode が重くなったらとりあえず restart ts-server しとけば良いという⾵潮そこで速度改善に取り組んでみることにした💪
課題

各アプリケーションで tsc の速度を計測したところ、いずれのアプリケーションも⼀定の速度改善を達成🥳🥳🥳 改善結果 Before After Diﬀ
App 1 40.21s 23.77s -41% App 2 27.01s 14.16s -48% App 3 14.54s 10.68s -27%

改善の要因は⼤きく分けると 3 つ👀 (パーセンテージは改善内容における割合) 1. Redux Toolkit 関連の型推論 (80%!!) 2.
Extract による Instantiation (10%) 3. 不要なスキーマ定義‧チェック (10%) 改善の要因

各 reducer の引数にある state について、 initialState の型を元に推論される部分に時間がかかっていた。 (Redux
Toolkit は v2.1.0) Redux Toolkit (Before)

initialState の型に名前を付けて切り出すことでキャッシュが効くようになり速度が改善。 1 ファイルにつき 800 - 900ms か
かっていたのが数 ms 程度で済むように🚀 Typescript の Performance に関する公式 doc にある Naming Complex Types のパターン Redux Toolkit (After)

Redux Toolkit (Before / After) ある App の型チェックをトレースしたときの Before /
After ⻘線で囲んだ部分が Redux Toolkit の createSlice をしているファイル

export function getNode<T extends Node['type']>( condition: Condition, nodeId: NodeId, type?:
T ): Extract<Node, { type: T }> export function getNode( condition: Condition, nodeId: NodeId, type: Node['type'] ) { // do something } 引数で受け取った type (リテラル型の union) をもとに Extract した型を返却する関数。 Extract<Node, { type: T }> の部分でチェックに時間を要していた。 Extract (Before)

export function getNode(condition: Condition, nodeId: NodeId): Node export function getNode(
condition: Condition, nodeId: NodeId, type: 'condition' ): ConditionNode export function getNode( condition: Condition, nodeId: NodeId, type: 'operator' ): OperatorNode export function getNode( condition: Condition, nodeId: NodeId, type?: Node['type'] ) { // do something } 関数オーバーロードを利⽤することで戻り値の情報は維持しつつ Extract を排除して、速度も改善🚀 コードが増え汎⽤性も失われたが、このドメイン領域では type は 2 種類しか存在せず、今後増えることも考えにくかったため、トレードオフを受け⼊れた形。 Extract (After)

ある型(右図では最終⾏の Types) を定義するときに、不要な zod schema (最後から 2 ⾏⽬)を介していた🥲 不要なスキーマ定義
export const typeASchema = z.object({ type: z.literal('A'), name: z.string(), }); export type TypeA = z.infer<typeof typeASchema>; export const typeBSchema = z.object({ type: z.literal('B'), count: z.number(), }); export type TypeB = z.infer<typeof typeBSchema>; export const typeCSchema = z.object({ type: z.literal('C'), value: z.string(), }); export type TypeC = z.infer<typeof typeCSchema>; // ↓この typesSchema はただの中間介在物でしかない、、 const typesSchema = z.union([typeASchema, typeBSchema, typeCSchema]); export type Types = z.infer<typeof typesSchema>;

弊社では、とある理由からリポジトリにビルド済みの js ファイルを複数配置している。それらは型チェックをする必要がないファイルだが、tsc コマンドの対象に含まれてしまっていた😇 不要な型チェック

tsc の速度は⼀定改善できたものの、 VSCode 上でチェックに時間がかかるファイルは依然として存在している😭 ドメインのコアになる部分にチェックに時間がかかる複雑な型があるので、それらを利⽤していると芋づる式にチェックに時間がかかってしまう⏰ (tsc はキャッシュが効くが、VSCode 上でのチェックは毎回全部⾛る) 今回紹介したのは型の使い⽅を⼯夫することで速度を改善した例だが、
この先は型⾃体に向き合う必要があるんだろうなと思っている💪 これからの課題

⼀枚絵で調査の流れ

型チェックのパフォーマンスデータを取得するには 2 つの⽅法がある tsc コマンドで出⼒プロジェクト全体のファイルを対象にチェックが⾛る。全体におけるボトルネックを把握するのに有⽤。 VSCode 上で出⼒現在開いているファイルを起点に関連するファイルのチェックが⾛る。
ファイル保存時の型チェックのボトルネックを特定するのに有⽤。型チェックに関するデータの取得

出⼒されるファイルは 2 種類📄 調査⽤ファイル trace.json どのファイルにどれだけ時間が費やされたかの詳細ログ最重要ファイルと⾔っても過⾔ではない！ types.json チェック対象になった型の⼀覧。特定の調査に必要。時として超巨⼤なファイルになる⚠

--noEmit ビルド結果の js ファイルを出⼒しない --extendedDiagnotics tsc コマンドの対象ファイル数や各プロセスにかかった時間等が表⽰される修正の結果、速度や Instantiations の数が変化したか確認するのに便利
--generateTrace 指定したディレクトリに trace.json と types.json を出⼒する速度改善には⽋かせない超重要オプション💡 tsc コマンドでのデータ取得 npx tsc -p path/to/tsconfig.json --noEmit --extendedDiagnostics --generateTrace traceDir

VSCode のオプションを使う場合、右図のように設定する。ログの位置が⾮常にわかりにくいが、コマンドパレットで tsserver.log を開いて、そこからエクスプローラを開くことでログのありかに辿り着ける。 VSCode
を開き続けている間はログが取得され続け、任意の期間だけログを取る事ができない😇 VSCode でのデータ取得(オプション) { "typescript.tsserver.enableTracing": true, "typescript.tsserver.log": "verbose" }

VSCode の拡張機能を使うことでもデータ取得が可能。オススメ！前回の TSKaigi で登壇されていた ypresto さん作成の拡張機能！コマンドパレットから任意のタイミングで
trace ログの ON/OFF を切り替えられる👏 これのおかげで調査がめちゃ捗りました、ありがたやありがたや🙏 VSCode でのデータ取得(拡張機能)

trace.json の解析にはツールを利⽤する about://tracing ブラウザに標準搭載されている。開くと Perfetto UI をオススメしてくる。 Perfetto UI Web
アプリ。もともと Android ⽤のツールだった模様。 Speedscope ⭐ オススメ！軽くて操作も直感的で⼀番使いやすかった。 trace.json の解析

trace.json の解析型チェックに時間がかかっているファイルが帯の⻑さから特定できる

ファイルのどこに時間がかかっているか特定するために下⽅向に進んでいく🛤 pos と end は AST 形式での位置を⽰しているので、AST 解析ツールを使って trace ファイルの内容とソースコードを照合していく🧐
AST でのポジション特定

structuredTypeRelatedTo を深掘りするためには、どこを参照しているのか知るために types.json を⾒る必要がある🔍 types.json

types.json にはチェック対象となった型情報がすべて出⼒されるため、対象によっては超巨⼤ファイルになってしまう⚠ ⾃分の環境では、3GB ほどのファイルが出⼒されたりした😇 そうなると出⼒にも時間もめっちゃかかる、、 trace.json と types.json の出⼒はシーケンシャルに⾏われるので、types.json
の出⼒が終わるまで tsc コマンドは実⾏中になってしまうのにも注意。 types.json の注意

調査対象によっては types.json は不要な場合もある。最初は trace.json の出⼒が終わったタイミングでいちいちプロセスを kill し
たりしていたが、 tsc のコードに⼿を加えてしまうのが⼀番⼿っ取り早かった🔧 node_modules/typescript/lib/tsc.js の dumpTypes() をコメントアウト🥷 types.json が不要な場合は… [email protected] の例

調査の流れおさらい

デモ調査の流れを簡単にデモしてみます🤖 (時間なかったらスキップ)

とにもかくにもまずは計測してみることが⼤事☝ やみくもに⼿を打つのではなく、影響の⼤きいボトルネックから⽴ち向かっていこう💪 まとめ

おわり

型チェック速度改善奮闘記⌛

型チェック速度改善奮闘記⌛

Kenta TSUNEMI

More Decks by Kenta TSUNEMI

Other Decks in Technology

Featured

Transcript