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、フォーマット、型チェック、診断が儀式なしで実行できるほど高速になると、品質は特別なイベントではなくなります。
それが通常の働き方になります。