Native Code-Generierung

Mit der Unterstützung von Luau für die native Codegeneration können Server-Skripte in deiner Erfahrung direkt in die Maschinencode-Anweisungen kompiliert werden, die CPUs ausführen, anstatt regulären Bytecode, auf dem die Luau-VM arbeitet.Diese Funktion kann verwendet werden, um die Ausführungsgeschwindigkeit für einige Skripte auf dem Server zu verbessern, insbesondere diejenigen, die eine Menge numerischer Berechnungen durchführen, ohne zu viele schwere Luau-Bibliotheken oder Roblox-API-Aufrufe zu verwenden.

Aktiviere die native Codegenerierung

Um die native Code-Erzeugung für ein Script zu aktivieren, füge den --!native -Kommentar oben ein:¹

--!native

print("Hello from native code!")

Dies ermöglicht die native Codegenerierung für alle Funktionen im Skript, das. PL: die Skriptsund den obersten Umfang, wenn er als profitabel angesehen wird.Es sind keine zusätzlichen Änderungen erforderlich; das Verhalten der nativen ausgeführten Skripte ist genau das gleiche wie zuvor und nur die Leistung ist anders.Alle Funktionen der Luau-Sprache und alle Roblox-APIs bleiben unterstützt.

Alternativ kannst du die native Codegeneration für eine einzelne Funktion aktivieren, indem du das Attribut @native hinzufügst:

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

Best Practices

Die folgenden Tipps helfen Ihnen, die meisten Vorteile der nativen Codegeneration zu nutzen:

• Es ist am besten, diese Funktion innerhalb von Skripten zu aktivieren, die viel Berechnung direkt innerhalb von Luau durchführen.Wenn du viele mathematische Operationen auf Tabellen und insbesondere auf buffer Arten hast, kann das Skript ein guter Kandidat sein.

• Nur die Funktionen des Skript, das. PL: die Skriptswerden nativ kompiliert.Der Code im oberen äußeren Bereich wird oft nur einmal ausgeführt und profitiert nicht so sehr wie Funktionen, die mehrmals aufgerufen werden, insbesondere diejenigen, die jede Sekunde aufgerufen werden.

• Es wird empfohlen, die Zeit zu messen, die ein Skript oder eine Funktion benötigt, mit und ohne native Kompilierung, um zu entscheiden, wann es am besten ist, es zu verwenden.Das Skript-Profiling-Werkzeug kann die Leistung von Funktionen messen, um informierte Entscheidungen zu treffen.

• Es kann verlockend sein, den --!native Kommentar in jedem Skript zu platzieren, nur im Fall, dass einige von ihnen schneller ausgeführt werden, aber die native Code-Generierung hat einige Nachteile:

  • Die Compilierungszeit des Codes ist erforderlich, was die Startzeit der Server erhöhen kann.
  • Zusätzliche Speicher sind belegt, um nativ kompilierten Codeszu speichern.
  • Es gibt ein Limit für die gesamte zulässige Menge nativ kompilierter Code in einem Erlebnis.

Diese Probleme können durch die sorgfältige Verwendung des Attributes @native gelöst werden.

Code zu vermeiden

Während alle Funktionen mit oder ohne native Code-Generierung aktiviert gleich verhalten, werden einige von ihnen nicht native ausgeführt und könnten zu einer De-Optimierung oder einem Rückgriff auf die interpretierte Ausführung führen.Dazu gehören:

• Verwendung veralteter getfenv() / setfenv() Anrufe.
• Verwendung verschiedener eingebauter Luau-Funktionen wie math.asin() mit nicht-numerischen Argumenten.
• Das Übersenden unzureichend typisierter Parameter an typisierte Funktionen, zum Beispiel das Ausrufen von foo(true), wenn foo als function foo(arg: string) deklariert wird.Denken Sie daran, immer die richtigen Typ-Annotations zu verwenden.

Wenn Sie den Skript-Profiler verwenden, können Sie die Zeit vergleichen, die für eine reguläre Version der Funktion versus die kompilierte native Version benötigt wird.Wenn eine Funktion innerhalb eines --!native Skripts oder mit @native markiert wird, scheint sie nicht nativ ausgeführt zu werden, kann ein oder mehrere Faktoren aus der oben aufgelisteten Liste die De-Optimierung auslösen.

Verwende Typ-Annotations

Native Code-Generierungsversuche versuchen, den wahrscheinlichsten Typ für eine bestimmte Variable zu inferieren, um Codepfade zu optimieren.Zum Beispiel wird davon ausgegangen, dass a + b an Zahlen ausgeführt wird, oder dass ein Tabellenzugriff in t.X erfolgt.Angesichts der Operatorüberlastung können jedoch a und b Tabellen oder Vector3 Arten sein, oder t kann ein Roblox-Datentyp sein.

Während die native Codegeneration jede eingebenunterstützt, können falsche Vorhersagen unnötige Überprüfungen auslösen, was zu einer langsameren Codeausführung führt.

Um einige allgemeine Probleme zu lösen, werden Luau-Typ-Annotations auf Funktionsargumente überprüft, aber es wird besonders empfohlen, Vector3 Argumente anzugeben:

--!native

-- es wird davon ausgegangen, dass "v" ein tisch ist; die funktion ist aufgrund von tabellenüberprüfungen langsamer
local function sumComponentsSlow(v)
	return v.X + v.Y + v.Z
end

-- ""v" wird als Vector3 deklariert; Code für Vektoren wird spezialisiert generiert
local function sumComponentsFast(v: Vector3)
	return v.X + v.Y + v.Z
end

Studio-Tooling

Die folgende Studio-Tooling wird für --!native Skripte und @native Funktionen unterstützt.

Fehlerbehandlung

Die allgemeine Debugging von Skripten wird unterstützt, aber die Ansichten für Lokale/Upvalues können unvollständig und fehlende Variablen aus Anrufstapel-Frames sein, die native ausgeführt werden.

Beachten Sie auch, dass beim Debuggen von Code, der für die native Kompilierung ausgewählt wurde, das Platzieren von Unterbrechungspunkten die native Ausführung für diese Funktionen deaktiviert.

Skript-Profiler

Im Skript-Profilierer zeigen Funktionen, die native ausgeführt werden, neben ihnen <native> an:

Wenn eine Funktion markiert oder innerhalb einer Skript nicht die Annotation zeigt, kann diese Funktion möglicherweise nicht native ausgeführt werden, wegen der Platzierung von Bruchpunkt , Verwendung von deaktiviertem Code oder unpassender Typ-Annotations .

Luau-Haufen

Im Luau-Speicher-Profiler zeigt sich die von nativen Funktionen verwendete Speicher als [native] Elemente im Diagramm an.

Größenanalyse

Jedes native kompilierte Skript verbraucht Speicher.Wenn die Größe des kompilierten Codes ein vordefiniertes Limit erreicht, stoppt die native Kompilierung und der übrige Code wird nicht-nativ ausgeführt.Dies macht es unerlässlich, Skripte sorgfältig für die native Kompilierung auszuwählen.

Um die native Codegröße einzelner Funktionen und Skripte zu überwachen:

1. Stellen Sie sicher, dass Sie in Server -Ansicht durch die Client/Server-Umschalttaste sind.
2. Beschwöre debug.dumpcodesize() von der Befehlsleiste.

Im Ausgabe-Fenster siehst du die Gesamtzahl der Skripte und Funktionen, die bis zum Zeitpunkt der Ausführung nativ kompiliert wurden, die von ihrem nativen Codesverbrauchte Speicher und das native Code-Größenlimit.Nach der Zusammenfassung siehst du eine Tabelle für jedes nativ kompilierte Skript in absteigender Reihenfolge der Skriptgröße.

Für jedes Skript, das. PL: die Skriptszeigt die Ausgabe die Anzahl der kompilierten Funktionen und den Konsum des nativen Code-Speichers an.Jede Funktion wird dann in absteigender Reihenfolge der nativen Codegröße aufgelistet, mit anonymen Funktionen, die als [anonymous] und gesamten Skripten angezeigt werden, die als [top level] angezeigt werden.In der letzten Spalte wird der Prozentsatz im Hinblick auf das native Codegrößenlimit berechnet.Beachten Sie, dass die native Codegröße von Funktionen genau gemeldet wird, aber der Speicherverbrauch für Skripte auf die nächste Seitengröße gerundet wird.

Beschränkungen und Fehlersuche

Die Kompilierung von Code in Anweisungen für eine bestimmte CPU erfordert zusätzliches Speicher-Speicher.Zusätzlich kann die Optimierung komplexer Funktionen zu viel Zeit benötigen, um durchgeführt zu werden.Das Erreichen eines internen Limits meldet einen Fehler im Studio-Ausgabefenster Output, einschließlich: