ジェネレーターのパフォーマンスを向上させるためのヒント

対策 1: 賢いランタイムを開発し、そのランタイムを活用するコードを生成する

今振り返ってみると、最初にコードジェネレーターを設計したとき、明らかなパターンに従っていました。基本的に、必要かどうかに関係なく、すべてのコードはジェネレーターテンプレートに直接入力されました。次の簡単な例は、以前のアプローチを簡単に示しています。

図 2 のジェネレーターテンプレート内の Java クラスは、IGenSelControlled インターフェースを直接実装します。saveAndValidate() や collectDelegateChanges() などの定型メソッドはテンプレートに直接含まれていますが、入力モデルに応じてメソッドの動作に違いはありません。メソッドの実装はまったく変わりません。実際、実装は常に同じです。同じ図 2 からもわかるように、同じ特性のメソッドが 1 つではなく複数存在します。

図 3 は、そのジェネレーターテンプレートのリファクタリングされたバージョンを示しています。Java クラスは別の Table クラスを拡張しました。上記の静的コードはすべて拡張クラスに実装されます。さらに、入力モデルの影響を受ける動作は、ブール型プロパティの形式で実装されます。これは、図 3 のコンストラクター宣言で確認できます。Table クラスの動作を構成するには、プロパティマクロが適用された 3 つの異なるブールスイッチを使用できます。さらに、前者のメソッド selectionChanged() は、より複雑なジェネレーターフラグメントがどのようにリファクタリングされたかを示しています。コードの静的部分はランタイム Table クラスに移動しましたが、動的部分は calcSelectionSummeryLineText() に移動しました。このメソッドにはパラメーターと戻り値が付属します。メソッド自体は非常にコンパクトです。ドメインロジックを計算する式は、入力モデルから生成されたクラスに渡されます。ここで、そのメソッドは Table クラスによって呼び出され、図 2 と同じ動作に似ています。

全体として、独自のコードジェネレーターでの同様のリファクタリングにより、生成される行数が 100 万行以上から 484,000 行まで削減されます。静的コードをジェネレーターテンプレートからランタイムに移動することにより、生成およびコンパイルされるコードの量が半分になりました。これにより、開発者マシンでの生成とコンパイル時間が約 2 分短縮されます。非常に重要な改善です。コードを生成するための強力なランタイム環境を構築することを強くお勧めします。

対策 2: 概念を名前で参照しないでください

MPS は、これまでモデル生成パフォーマンスレポートをサポートしてきました。このレポートタイプは、ジェネレーターの設計者に、モデルごとに使用されるさまざまな生成ステップに関するパフォーマンスのインサイトを提供します。レポートは、最も時間を費やしているジェネレーターのステップが最初にリストされるように並べ替えられます。ジェネレーターのステップに費やされた時間と、単一ステップ内のアクティビティを簡単に特定できます。また、ウィービングルール、リダクションルール、デルタ変更に費やした時間も表示されます。私たちにとって特に価値があるのは、参照の復元に費やした時間です。

参照の復元は、参照マクロでターゲット名のみを操作する場合に、実際のターゲットの概念を検索するプロセスです。MPS 参照マクロは、ターゲットの概念 (node<> または node-ptr<>) または単に名前 (文字列) を返すことができます。プレーン名を使用する場合、MPS は出力モデル内で参照されるターゲットを見つける作業を引き継ぎます。ただし、この追加作業には時間がかかる場合があります。これは、「参照の復元」として報告される期間と同じです。

MMS プロジェクトのコンテキストでは、参照の復元に費やされた時間は一見すると重要ではありませんでした。ただし、140 個のモデルと複数の生成ステップを使用している場合、参照の復元に 1 ～ 2 秒の時間がかかります。ジェネレーターの別のリファクタリングで、ターゲットの概念の参照に一般的に対処しようとしました。これを行うには複数の方法が考えられます。

名前による参照に関する主な対策は、ジェネレーターマッピングラベルを積極的に使用することです。以下の図 4 に示すように、マッピングラベル「DelegateFD」がループマクロに付加され、クラス内で生成された各クラスフィールドにラベルが付けられます。このラベル付けプロセスにより、入力概念インスタンスと生成された概念インスタンスの間に関係が作成されます。後で、ジェネレーターの設計者は、これらのラベルを介して入力コンセプトによって生成されたコンセプトを検索できます。通常、これが参照マクロの目的です。特定の入力概念インスタンスに基づいて、出力モデルで関連して生成されたターゲットを参照したいと考えています。図 4 に示す例では、ジェネレーターの設計者は、生成されたクラスフィールドの 1 つを検索する可能性があります。

ラベルのマッピングを試すのは簡単なプロセスです。必要なのは、生成されたコードにラベルを付け、それらのラベルを参照マクロで使用することだけです。これは非常に簡単です。ラベル付けされた生成コードが、参照マクロが適用されたコードと同じ出力モデル内に存在する限り、ラベルのマッピングによって追加の負担が追加されることはありません。モデル間でインスタンスを参照する場合、状況は少し複雑になります。デフォルトでは、異なる入力モデルと出力モデル間でラベルにアクセスすることはできません。たとえば、当社のジェネレーターの場合、そのような状況はすぐに起こります。モデル A では、「サービスコンポーネント」S が宣言されており、そのサービスコンポーネント S はモデル B からも使用され、アクセスされます。モデル B で生成されたコードは、モデル A で生成されたコードを参照する必要があります。このシナリオには 2 つの解決策があります。

モデル間の変換を行う代わりにテキストを直接生成する場合、参照の復元は不要になります。これは、ジェネレーターでモデル間を参照するときに使用したものです。図 4 のスーパークラスコンストラクター呼び出しでは、JetBrains BaseLanguageInternal 言語の概念を使用して、実行時に Java クラスのクラスインスタンスを決定します。この概念は、標準の Java .class 式とは異なります。テキストとして完全修飾名を受け入れ、出力モデル内の概念の準備タイプを決定するための分類子を受け入れます。その概念に対応するジェネレーター (JetBrains TextGen) は、指定された名前に .class を追加することで Java テキストに直接変換します。図 4 からわかるように、参照マクロの代わりにプロパティマクロが使用されています。この BaseLanguageInternal 概念を使用する場合、参照の復元は廃止されます。

TextGen を使用してテキストに直接変換する、さらに類似した BaseLanguageInternal の概念があります。モデル間の参照が必要な場合、ジェネレーター内のそれらの一部に依存しました。これにより、MMS 全体の生成プロセスでさらに約 45 秒節約されます。BaseLanguageInternal のものはいくぶん「内部」的なものであるように見えますが、ジェネレーターのリファクタリングを必要とするような概念への重大な変更は発生しませんでした。テキストを直接生成するこのアプローチは、この状況におけるクロスモデル参照シナリオに対する実行可能な解決策です。テキストが生成された後は、他の変換を適用できないことに注意してください。

モデルの相互参照状況を処理するために推奨される新しいアプローチ、つまりチェックポイントと組み合わせた生成計画もあります。生成計画を使用すると、開発者はモデルの生成順序を明示的に指定できるため、生成プロセスをより適切に制御できるようになります。生成計画では、生成プロセスに含める必要があるすべての言語をリストし、適切に順序付けし、オプションでジェネレーターが現在の一時モデルを保存するチェックポイントを指定します。これらのモデルは、生成プロセスのさらに後の自動モデル間参照解決に使用できます。従来のアプローチでジェネレーターの「ジェネレーターの優先順位」を指定しましたが、さらにジェネレータープランも試してみました。生成計画を立てるのは実に簡単です。ジェネレーターを上から順にリストすることで、すべての優先順位を指定できます。言語スタックとそのジェネレーターの完全な計画を図 5 に示します。

ご覧のとおり、モデルの相互参照に関しては BaseLanguageInternal アプローチに依存しているため、計画ではチェックポイントを指定しませんでした。ただし、モデル A で「サービスコンポーネント」 S が宣言され、そのサービスコンポーネント S がモデル B からも使用され、アクセスされる状況に似せるために、デモ目的で簡単な言語を作成しました。非常に単純化した「サービスコンポーネント」は次のようになります。ジェネレーターを使用して Java クラスに変換されます。モデル B から生成されたコードは、モデル A の生成されたコード内のまさにそのクラスを参照する必要があります。生成計画にチェックポイントを追加すると (つまり、デモ言語の「applygenerator」コマンドの後に「checkpoint」キーワードを追加するだけです)、すべてがすでに完了しています。MPS は、ラベルと入力によって生成されたコンセプトを検索するときに、チェックポイントモデルを自動的に考慮します。メカニズムはモデル内参照解決の場合とまったく同じです。ジェネレーターの設計者として、追加で考慮すべきことはありません。実際、デモ言語でチェックポイントを使用して生成計画をセットアップすることはまったく面倒ではないことがわかり、さらに、ラベルを使用したクロスモデル参照もすぐに機能しました。

対策 3: ジェネレーターでの「.type」の計算には注意する

Jetbrains.mps.lang.typesystem 言語は、ジェネレーター内の任意のノードの型を決定するための .type 操作を提供します。通常、さまざまな決定は式の型に基づいて行われるため、これは式を処理する場合に非常に役立ちます。例: 式に適用できるメソッドは、その式の最も外側の概念が変数参照であるか別のメソッド呼び出しであるかではなく、その式の型に依存します。

特定のノードのタイプに基づいてジェネレーターでさまざまな変換を実行することは珍しいことではありません。ただし、.type を使用した型の計算は、かなり CPU を集中的に使用する操作です。開発マシンでいくつかの測定を行いました。大まかな指標として、単一の .type 計算には 2 – 30 ミリ秒かかります。これは最初は特に問題にならないように見えますが、MMS 全体が 400,000 ノードで構成されていることを考慮すると、慎重に適用しないと、ジェネレーターでの .type 計算の時間が増加する可能性があります。

設定で「タイプ計算に費やした時間」を選択すると、ジェネレーターでの .type 計算に費やした時間も、前述の「モデル生成パフォーマンスレポート」にレポートされます。残念ながら、この場合、ジェネレーターの設計者はパフォーマンス情報に圧倒されてしまいます。ご想像のとおり、これらのパフォーマンスに関するヒントをすべて確認するのは、非常に面倒なプロセスです。

リファクタリングの 1 つは、まったく同じ式の型計算が複数回行われないようにすることで、生成時間を最小限に抑えることを特に目的としていました。ケースは次のとおりです。私たちの言語の 1 つでは、非プリミティブ値の算術演算が導入されました (Java BigDecimal クラスなど)。この言語のユーザーは、add() へのメソッド呼び出しの代わりに、単純に「+」を使用できます。コードジェネレーターは、コード内の式のタイプをインスペクションすることにより、コードをわずかに再フォーマットします。型が BigDecimal で「+」が適用されている場合、式を変換する必要があります。

比較演算 (== / < / <= など) も言語の一部として許可したため、compareTo() メソッドの呼び出しに変換する必要がありました。同じ再フォーマットロジックを言語内のすべての比較とすべての算術演算に適用する必要がありました。素朴なアプローチでは、変換先の異なるメソッド呼び出しごとに 1 つの異なる MPS ジェネレーター削減ルールを作成しました ( 図 6 を参照)。このような各リダクションルールには .type 計算の条件が含まれていたため、入力モデルの式の同じ部分に対して複数の計算が行われることになりました。

これらの計算を最小限に抑えるために、リファクタリングによる段階的なプロセスを導入しました。左部分と右部分を持つ何らかの形式の操作が BigDecimal に適用されると、一時オブジェクトで計算された型を生成コンテキストに保存し、その情報を再利用します。つまり、一般的な BinaryOperation に対して「継承」が有効になっているリダクションルールを 1 つだけ使用して、条件内の左側の式の型をチェックします。その型が BigDecimal または Int の場合、その型が保存され、適切な式が評価されて保存されます。その情報は MPS テンプレートスイッチに渡され、それに応じて操作が変換されます。テンプレートスイッチには .type 計算が含まれておらず、同じ式に対して複数の計算が存在することもありません。

ジェネレーターでの .type 計算は CPU を大量に使用する操作であるため、生成が大幅に遅くなる可能性があります。私たちの場合、このリファクタリングによってパフォーマンスがわずかに向上しただけでした。ただし、ジェネレーターに対する最も重要な変更は、生成されるコードの総量が最小限に抑えられたことです。当然のことながら、これにより、生成中にインスペクションされる式の数が大幅に減少し、生成プロセスで型の計算が繰り返される問題の軽減に役立ちました。