ネイティブコード生成

ネイティブコード生成に Luau のサポートがあるため、Luau VM が実行している通常のバイトコードではなく、CPU が実行するマシンコード指示に直接スクリプトがコンパイルできます。この機能は、サーバー上の特定のスクリプトの実行速度を向上させるために使用でき、特に多くの重い Luau ライブラリまたは Roblox API 呼び出しを使用しない数学計算を持つスクリプトを改善します。

ネイティブコード生成を有効にする

To enable native code generation for a , add the コメント at the top:¹

--!ネイティブ

print("Hello from native code!")

これにより、スクリプトのすべての機能とトップレベルのスコープに対するネイティブコード生成が有益であると判断された場合があります。追加の変更は必要ありません; ネイティブで実行されるスクリプトの動作は、以前と同じであり、パフォーマンスのみが異なります。Luau 言語のすべての機能と、すべての Roblox API がサポートされ続けます。

代わりに、@native 属性を追加して個々の機能のネイティブコード生成を有効にすることもできます：

@native
local function f(x)
  return (x + 1)
end

最良の実践

次のヒントは、ネイティブコード生成から最大限に利益を得るのに役立ちます：

• Luau 内で多くの計算を直接行うスクリプト内でこの機能を有効にするのが最善です。テーブルや特に buffer タイプに多くの数学操作がある場合、スクリプトは良い候補になる可能性があります。

• スクリプトの 機能 だけがネイティブでコンパイルされます。トップ外部の スコープ のコードは、多くの回呼ばれる機能と同じくらい実行されることは少なく、特にすべてのフレームで呼ばれる機能は、より多くの利点がありません。

• スクリプトまたは関数がネイティブコンパイルでどのくらいの時間がかかるかを測定し、使用するタイミングを判断するために、ネイティブコンパイルなしで測定することをお勧めします。スクリプトプロファイラ ツールは、情報に基づいた意思決定を行うために、機能のパフォーマンスを測定できます。

• すべてのスクリプトに コメントを配置することは誘惑的かもしれませんが、ネイティブコード生成にはいくつかの欠点があります：

  • コードのコンパイル時間が必要で、これはサーバーの起動時間を増加させる可能性があります。
  • 追加のメモリは、ネイティブにコンパイルされたコードを保存するために使用されます。
  • エクスペリエンス内のネイティブにコンパイルされたコードの合計許可量に制限があります。

これらの問題は、@native 属性の賢明な使用により解決できます。

回避するコード

すべての機能がネイティブコード生成を有効にしても無効にしても同じ動作をするが、一部はネイティブで実行されず、最適化が低下したり、インタープリテーション実行にバックアップされたりする可能性がある。これには以下が含まれます:

• 廃止された getfenv() / setfenv() 呼び出しの使用。
• 非数字の引数で math.asin() のような様々な Luau 内蔵機能の使用。
• 不適切にタイプされたパラメータを型付き関数に渡し、例えば、foo(true) を呼び出すときに、foo が宣言されるときに、function foo(arg: string) を呼び出します。常に正しい タイプのアノテーションを使用するように注意してください。

スクリプトプロファイラ を使用すると、ファンクションのレギュラーバージョンとネイティブにコンパイルされたバージョンの時間を比較できます。 スクリプト内の関数、または スクリプトにマークされた がネイティブで実行されているように見えない場合、上記のリストから 1つまたは複数の要因が、 最適化を停止する可能性があります。

タイプアノテーションを使用

ネイティブコード生成は、コードパスを最適化するために、特定の変数の最も可能なタイプを推測しようとします。たとえば、a + b が数字で実行されるか、またはテーブルが t.X でアクセスされると想定されます。ただし、オペレーターのオーバーロードにより、a および b はテーブルまたは Vector3 型、または t は Roblox データタイプかもしれません。

ネイティブコード生成はどんなタイプでもサポートしますが、予測ミスが不必要なチェックをトリガーし、コードの実行が遅くなる可能性があります。

いくつかの共通の問題を解決するには、Luau タイプの関数引数のアノテーションがチェックされますが、特に Vector3 引数にアノテーションを付けることをお勧めします：

--!ネイティブ

-- 「v」はテーブルと推定され、機能はテーブルチェックにより遅く実行されます
local function sumComponentsSlow(v)
	return v.X + v.Y + v.Z
end

-- 「v」はベクトル3であると宣言され、ベクトル用のコードが生成されます
local function sumComponentsFast(v: Vector3)
	return v.X + v.Y + v.Z
end

スタジオツール링

次のスタジオツールは、--!native スクリプトと @native 機能に対応しています。

デバッグ

スクリプトの一般的な デバッグ はサポートされますが、ローカル/アップバリューのビューは不完全で、ネイティブで実行されている 呼び出しスタック フレームから欠落した変数があります。

また、ネイティブコンパイル用に選択されたコードをデバッグするとき、ブレークポイント を配置すると、それらの機能のネイティブ実行が無効になります。

スクリプトプロファイラ

スクリプトプロファイラ では、ネイティブで実行される機能が次の横に表示されます:<native>

機能が またはスクリプト内の の標識が を表示しない場合、その機能は、ブレークポイントの配置、 忌み嫌われたコードの使用 、または一致しない タイプのアノテーション のため、ネイティブで実行されない可能性があります。

Luau ヘップ

In the Luau ヘープ profiler, ネイティブ機能によって取得されたメモリは、グラフの [native] 要素として表示されます。

サイズ分析

ネイティブにコンパイルされたすべてのスクリプトがメモリを消費します。コンパイルされたコードのサイズがプリ定義された制限に達すると、ネイティブコンパイルが停止し、残りのコードは非ネイティブで実行されます。これは、ネイティブコンパイルのためにスクリプトを慎重に選択することが必須です。

個々の機能とスクリプトのネイティブコードサイズを監視するには：

1. Make sure you're in サーバー ビューを通じて クライアント/サーバー切り替え ボタンで確認してください。
2. 呼び出す debug.dumpcodesize() から コマンドバー 。

出力 ウィンドウ では、呼び出しポイントまでネイティブにコンパイルされたスクリプトと機能の合計数、ネイティブコードによって消費されたメモリ、ネイティブコードサイズ制限を見ることができます。まとめ要の後、コードサイズが下降順で表示されるネイティブにコンパイルされたスクリプトの表を見ることになります。

各スクリプトについて、出力はコンパイルされた機能数とネイティブコードメモリ消費を表示します。それぞれの機能は、ネイティブコードサイズが下降順にリストされ、匿名機能は [anonymous] 、全体のスクリプトは [top level] と表示されます。最後の列では、パーセンテージはネイティブコードサイズ制限に対して計算されます。機能のネイティブコードサイズは正確に報告されますが、スクリプトのメモリ消費は最も近いページサイズに丸められます。

制限とトラブルシュート

特定の CPU 用のコードを指示に変換するには、追加のストレージメモリが必要です。さらに、複雑な機能の最適化は実行に時間がかかりすぎる可能性があります。内部制限に達すると、Studio の 出力 ウィンドウにエラーが報告され、以下を含みます：