Vize
パフォーマンスチューニング
フロントエンド ツールチェーンのパフォーマンス チューニングは 1 つのコツではありません。
「Rust で書き直して」グラフが上がるのを待つわけではありません。これは、時間がどこにかかるか、メモリがどのくらいの頻度で移動するか、どれだけの作業が重複するか、アーキテクチャによって改善が複合化されるかどうかについての、小さくて具体的な決定の長期にわたる一連の作業です。
このメモは、Vize が最適化を続けていることの知識を共有するものです。
ループ全体を測定する
コンパイラのベンチマークは便利ですが、開発者のエクスペリエンス全体を網羅するものではありません。
Vue ツールチェーンにはいくつかのフィードバック ループがあります。
- 開発サーバーでの 1 つのファイルのコンパイル
- 完全な実稼働ビルド
- 多くのファイルをリンティングする
- 多くのファイルをフォーマットする
- 生成された仮想ファイルの型チェック
- ユーザーが入力している間のエディター診断
- 実際のアプリケーション全体にわたる CI チェック
- AI が生成したパッチは繰り返し検証されます
最も遅いループが必ずしも最も明らかなループであるとは限りません。
単独では高速に見える関数でも、すべてのステージで実行すると有害になる可能性があります。すべてのトークン、すべての AST ノード、すべての診断、および生成されたすべてのセグメントで割り当てが発生する場合、小さな割り当てでも問題になる可能性があります。
これが、Vize がパフォーマンスをコンパイラーのプロパティだけでなくツールチェーンのプロパティとして扱う理由です。
重複作業を避ける
最も信頼性の高い最適化は、作業を 2 回実行しないことです。
断片化されたセットアップでは、同じ .vue ファイルを次のように個別に解析できます。
- コンパイラ
- リンター
- フォーマッタ
- 型チェッカー
- エディターの統合
- コンポーネントのドキュメントパイプライン
これには費用がかかりますが、より深刻な問題はアーキテクチャにあります。すべてのツールがファイルについて独自の理解を構築する場合、パフォーマンスのチューニングはローカルで限定的なものになります。
Vize は共有構造を中心に設計されています。
- 可能な限り一度解析する
- SFC ブロック境界を安定に保つ
- コンパイラと診断全体でテンプレート構造を再利用します
- セマンティック分析で複数の消費者にフィードを提供できるようにする
- 入力が変更されない限り、仮想 TypeScript の再生成を回避します
多くの場合、最良の最適化とは、より適切な所有権境界を設定することです。
割り当ては詳細ではなく機能です
フロントエンド ツールは、トークン、ノード、スパン、文字列、スコープ、診断、生成されたコード フラグメントなど、多くの小さなオブジェクトを処理します。
これらのオブジェクトが無造作に割り当てられた場合、ツールチェーンがどこにいても料金を支払います。
Vize は割り当て動作に大きな圧力をかけます。
- 有効期間の短いコンパイラー データ用のアリーナ スタイルのストレージ
- 繰り返される識別子または名前が重要な場合の文字列インターン
- コピーされた部分文字列の代わりにスパンをコンパクトにします
- 所有権が不要な借用スライス
- 大規模なクローン構造の代わりに安定した内部 ID
目標は、それ自体のためにコードを賢くすることではありません。
目標は、ホット パスを退屈なものにすることです。割り当て、コピー、キャッシュ ミスを減らし、アロケーターがプロファイルの一部になる理由を減らします。
並列処理には形状が必要
並列処理は「スレッドをオンにする」ことではありません。
問題に明確な境界がある場合に最も効果的です。
- 多くの独立したファイル
- 決定論的な集計
- 予測可能な出力順序
- 共有されたグローバルな突然変異はありません
- 制限されたキャッシュとセッション
Vue のコンパイル、リンティング、およびフィクスチャ スイープは、多くの場合、自然なファイル レベルの並列形式をとります。ただし、型チェックとエディターのワークフローはプロジェクトの状態に依存するため、より複雑です。
そこで Vize は質問を次のように分割します。
- このファイルレベルの作業は独立して実行できますか?
- このステップには常駐プロジェクト セッションが必要ですか?
- 出力順序はユーザーに表示されますか?
- スレッド数が変わっても診断は安定していますか?
- 並列処理により、勝利が消えるほどメモリ負荷が増加しますか?
高速だが不安定な出力では十分ではありません。パフォーマンスの仕事では信頼を維持する必要があります。
ソース マッピングがホット パスになる可能性がある
Vue ツールは中間コードを生成することがよくあります。
つまり、適切な診断にはすべて戻るパスが必要です。
- 元のテンプレートに TypeScript を生成
- SFCソースへのレンダリングコードを生成
- 変換されたスタイルまたはスクリプト出力を元のブロックに出力
- 仮想モジュール ID を実際のファイルに戻す
ソース マッピングが遅かったり不正確だったりすると、ツールチェーン全体に影響が生じます。ユーザーには診断が間違った場所に表示されます。 AI 修復ループの座標が低下します。テストは脆弱になります。
したがって、ソース マッピングは解析と同様にパフォーマンスに注意を払う必要があります。
- スパンをコンパクトに保管
- パス正規化の繰り返しを避ける
- 生成されたセグメントメタデータを小さく保ちます
- スナップショットを使用してエッジケースをテストする
- 成功したコンパイル パスだけでなく、診断負荷の高いワークロードをプロファイルします。
診断は製品表面です。彼らのパフォーマンスは重要だ。
本物のプロジェクトが合成の快適さを打ち破る
マイクロベンチマークは、焦点を絞った質問に答えるときに役立ちます。
しかし、ツールチェーンは実際のプロジェクトに対して実行されると正直になります。
実際のプロジェクトには次のものが含まれます。
- 奇妙な依存関係のレイアウト
- 大型SFC
- レガシーパターン
- 自動生成されたコード
- 珍しいディレクティブ
- プラグインの規約
- パスのエイリアス
- プラットフォーム固有のエッジケース
だからこそ、Vize は現実世界のフィクスチャのスイープとスナップショットの構築に投資し続けています。目標は、素晴らしいテスト数を収集することではありません。目標は、運用コードが乱雑であるのと同じようにコードが乱雑な場合にのみ現れるパフォーマンスの崖を明らかにすることです。
パフォーマンスは製品の機能です
速度は行動を変えます。
チェックが遅い場合、チェックを実行する頻度が減ります。 フォーマットが遅いと、フォーマット保存が面倒になります。 型を認識したリンティングが遅い場合、チームはルールを無効にします。 CI が遅い場合、メンテナは変更をバッチ処理し、慎重にレビューしません。 AI の検証が遅い場合、エージェントはより大きくリスクの高い行動をとります。
高速ツールにより、より厳密なワークフローが実用化されます。
それが Vize の本当のパフォーマンスの議論です。目標は、ベンチマークの数値を向上させることだけではありません。目標は、厳密なパスをデフォルトのパスのように感じさせることです。
コンパイル、lint、フォーマット、型チェック、診断が儀式なしで実行できるほど高速になると、品質は特別なイベントではなくなります。
それが通常の働き方になります。