SYNX 3.8 ist überall schneller, und alle Parser sind sich endlich einig

SYNX 3.8.0 ist da, und wenn Sie nur Konfigurationsdateien schreiben, sehen Sie in den Dateien selbst nichts Neues, weil sich die Grammatik keinen Millimeter bewegt hat. Bewegt hat sich alles darunter: Den Rust-Kern, das TypeScript-Paket, die Bindings für Python und Node und alle sieben nativen Ports haben wir auf derselben Maschine und mit denselben Dateien gegen 3.7.4 gemessen und dann überall dort neu gebaut, wo die Zeit tatsächlich verloren ging.

Wie viel schneller

Die Kurzfassung, direkt im Format selbst:

# 3.7.4 -> 3.8.0, same machine, same files
rust
  config_2_5kb     38.6us -> 17.6us
  static_4mb       60.1ms -> 35.3ms
  active_1_2mb     81.0ms -> 22.5ms
typescript_node
  config_2_5kb     34.0us -> 20.4us
  active_1_2mb    297.5ms -> 31.1ms
python
  config_2_5kb     50.3us -> 17.6us
  synxl_100k      173.7ms -> 83.2ms

Den größten Sprung macht TypeScript bei großen Dokumenten mit Markern, und der Grund ist ein bisschen peinlich: Jeder :calc-Schlüssel ging seinen Ausdruck gegen jeden anderen Schlüssel im Dokument erneut durch, die Arbeit wuchs also mit dem Quadrat der Dateigröße. In Rust kam der größte Gewinn vom Speicher. Mit dem Systemallokator von Windows verbrachte ein einfacher Parse fast die Hälfte seiner Zeit damit, Speicher anzufordern, und 3.8.0 tut das bei statischen Dateien etwa dreimal und im aktiven Modus etwa fünfmal seltener. Das binäre .synxb-Format bekam dieselbe Behandlung: Die häufigsten Strings eines Dokuments erhalten jetzt die kürzesten Indizes, die Dateien sind in Rust 3 bis 20 Prozent und in TypeScript bis zu 40 Prozent kleiner, und dasselbe Dokument ergibt jetzt immer dieselben Bytes, was 3.7.4 nicht garantiert hat.

Die Parser waren sich gar nicht einig

Danach haben wir eigentlich nicht gesucht. Um sicherzugehen, dass der schnellere Code dieselben Ergebnisse liefert, haben wir dem Rust-Kern und dem TypeScript-Paket dieselben zufällig erzeugten Dokumente gegeben und die Ergebnisse verglichen, und bei 17 Prozent der !active-Dokumente kam etwas anderes heraus. Manchmal lag TypeScript falsch, manchmal Rust, und manchmal lag Rust bei jedem Lauf anders falsch: Es durchlief Objekte in der Reihenfolge einer Hash-Tabelle, sodass das Beispiel tax:calc / total:calc direkt aus der Spezifikation in ungefähr jedem zweiten Lauf mit CALC_ERR scheiterte.

Und als wir einmal angefangen hatten, fand sich mehr. Marker innerhalb von Listeneinträgen wurden in Rust überhaupt nicht angewendet. Synx.stringify und .synxb veränderten Daten auf dem Rückweg, "007" kam als Zahl 7 zurück und |+-Codeblöcke verloren ihre Einrückung, und 1.777 von 3.000 zufälligen Dokumenten überstanden den Hin- und Rückweg nicht. Einige Dokumente konnten sogar den ganzen Prozess beenden: :clamp:nan:5 brachte Rust zum Absturz, und eine Datei, die sich selbst einbindet, ließ den Stack überlaufen. Alle 55 dieser Fehler sind behoben, und mit dem finalen Code stimmen Rust-Kern und TypeScript bei allen 70.000 erzeugten Dokumenten überein.

Sieben Ports, alle auf 3.8.0

SYNX hat außerdem native Parser für Go, Java, .NET, Dart, C++, Swift und Godot, und die waren einige Releases zurückgefallen. Alle sind jetzt auf 3.8.0, auf dieselbe Weise gegen den Rust-Kern mit jeweils Tausenden erzeugter Dokumente geprüft, und es gibt keine Abweichungen mehr. Manche haben sich deutlich stärker verändert als andere: Die Ports für C++ und Swift brauchten für ein aktives Dokument von 1,2 MB 88 und 47 Sekunden und brauchen jetzt 33 und 95 Millisekunden, und das Godot-Addon ließ sich unter Godot 4.7 vorher nicht einmal kompilieren.

Aktualisieren

Ihre .synx-Dateien müssen nicht geändert werden. Die Pakete sind @aperturesyndicate/synx-format auf npm, synx-core auf crates.io und synx-format auf PyPI, die Ports kommen über ihre üblichen Registries. Wer synx-core direkt aus Rust verwendet: Objekte sind jetzt eine geordnete IndexMap statt einer HashMap, Code, der selbst eine HashMap baut und einpackt, braucht also ein .collect(), während alles, was über get und Iteration liest, unverändert kompiliert.

Eines kann das Format noch nicht ausdrücken: Eine Liste innerhalb eines Listeneintrags, auf den ein weiterer Eintrag folgt, übersteht Schreiben und Zurücklesen nicht, weil SYNX immer nur eine offene Liste kennt. Das ist für 4.0 geplant, zusammen mit kompakten Strings, die in einer Laborkopie des Kerns das Parsen um weitere 1,2- bis 1,5-mal beschleunigt haben.

Alle Änderungen mit Zahlen stehen im Changelog und im Release 3.8.0 auf GitHub.