Perry: TypeScript als natives Programm

Projektübersicht und die Rolle der Benchmark-Seite

Perry ist ein nativer TypeScript-Compiler, der in Rust geschrieben ist. Laut Repository-Beschreibung kompiliert er TypeScript direkt mit SWC und LLVM zu ausführbaren Dateien. Das README unter benchmarks/README.md ist nicht die Hauptdokumentation des Projekts, sondern eine eigene Benchmark-Seite. Sie vergleicht Perry mit Laufzeit-Pendants Node und Bun, einem TS-zu-nativem Pendant AssemblyScript mit json-as und Referenzpunkten in kompilierten Sprachen einschließlich Rust, Go, C++, Swift, Java, Kotlin und Python. Die nativen Compiler werden nicht als Pendants behandelt, sondern als Kalibrierung, um eine Untergrenze für handgeschriebenen, statisch typisierten, vorab kompilierten Code zu zeigen. Die Seite ist für Skeptiker konzipiert, mit offengelegter Implementierung, Flags und Methodikentscheidungen.

Benchmark-Methodik

Die Benchmark-Seite dokumentiert ihre Methodik detailliert. Hardware ist ein Apple M1 Max mit 64 GB RAM unter macOS 26.4. Die letzte Aktualisierung ist auf den 14. Mai 2026, Version v0.5.908, datiert. Jede Zelle wird 11-mal ausgeführt und berichtet Median, p95, Populationsstandardabweichung, Min und Max, nicht Best-of-N. CPU-Pinning verwendet auf macOS einen Scheduler-Hinweis und auf Linux striktes taskset-Pinning. Es gibt einen Pre-1.0-Hinweis: Perry ist bei v0.5.908, daher können Zahlen zwischen Releases zurückgehen. Die Seite erklärt auch eine beabsichtigte Asymmetrie: Node führt vorkompilierte .mjs-Dateien aus (Typen werden in einem ungemessenen Setup-Schritt von esbuild oder tsc entfernt), während Bun TypeScript-Quellcode direkt ausführt, weil direkte TypeScript-Ausführung das native Eingabeformat von Bun ist.

JSON-Benchmarks: Lazy Tape und seine Grenzen

Zwei JSON-Workloads sind zentral: Validieren-und-Roundtrip (Parsen dann Stringifizieren, ohne die geparsten Werte zu berühren) und Parsen-und-Iterieren (Parsen, Summieren eines Feldes aus jedem Datensatz, dann Stringifizieren). Perrys Lazy Tape, eingeführt in v0.5.204, baut ein Band mit 12 Bytes pro Wert anstelle eines materialisierten Baums und kann bei unveränderten Parses den ursprünglichen Blob für das Stringifizieren per memcpy kopieren, ähnlich wie simdjsons raw_json-Ansicht. Beim Validieren-und-Roundtrip ist Perry mit einem Median von 83 ms am schnellsten unter den dynamisch typisierten Laufzeiten, verglichen mit Bun bei 249 ms und Node bei 377 ms, aber simdjson führt mit 24 ms. Beim Parsen-und-Iterieren, wo das Band materialisiert werden muss, liegt Perrys Standard bei 425 ms, langsamer als seine eigene Mark-Sweep-Notluke (338 ms) und langsamer als Rust serde_json (182 ms) und Bun (251 ms). Die Seite dokumentiert auch eine RSS-Regression (Issue #745), die in v0.5.900 teilweise behoben wurde, aber Perry hat immer noch etwa das 2,5- bis 3-fache RSS seiner früheren Basislinie.

Compute-Mikrobenchmarks und das Fast-Math-Flag

Die Compute-Mikrobenchmarks umfassen fibonacci, loop_data_dependent, object_create, nested_loops und fünf Optimierungsproben: loop_overhead, math_intensive, accumulate, array_read und array_write. Fast-Math ist über das --fast-math-Flag, die Umgebungsvariable PERRY_FAST_MATH oder eine package.json-Einstellung opt-in. Es aktiviert LLVM reassoc und contract pro Instruktion auf f64-Operationen. Standardmäßig erzeugt Perry bit-exakte f64-Ausgabe mit Node. Bei loop_overhead liegt Perry standardmäßig bei 97 ms und fällt mit Fast-Math auf 12 ms, was C++ mit -ffast-math entspricht. Allerdings ist loop_data_dependent, das eine sequenzielle Abhängigkeitskette hat, nicht betroffen: Perry liegt sowohl mit als auch ohne Fast-Math bei 225 ms. Die Seite betont, dass dies Compiler-Flag-Proben sind, keine Laufzeitleistungsvergleiche, und dass die 8-fache Beschleunigung bei loop_overhead real ist, aber nur auf dieses spezifische faltbare Akkumulatormuster zutrifft.

Speicher- und GC-Stabilitätstests

Die Seite enthält sechs Speicher- und GC-Tests, jeweils unter drei GC-Modus-Kombinationen (Standard, Mark-Sweep-Notluke und Gen-GC mit Write-Barrieren), also 18 Läufe pro CI-Aufruf. Alle 18 Zellen bestehen im aktuellen Commit. Die Tests sollen spezifische Leckmuster erkennen, wie Block-Pinning, Sparse-Cache-Leaks und Closure-Umgebungs-Retention. Beispielsweise fiel test_memory_json_churn von 115 MB auf 91 MB, als in v0.5.237 die Generationen-GC zum Standard wurde. Die Seite zeigt auch eine historische RSS-Tabelle für bench_json_roundtrip, einschließlich der Regression und Teilkorrektur.

Was die Seite nicht misst

Das README listet explizit auf, was die Benchmarks nicht abdecken: GC-Latenz und Tail-Latenz, JIT-Warmup-Verhalten (Warmup-Iterationen werden ausgeführt, aber der echte Kaltstart wird nicht berichtet), Async/Await, jegliche I/O, realistische Anwendungslast, Speicherdruck unter Konkurrenz sowie Kompilierzeit oder Binärgröße (außer der Erwähnung, dass Hello World etwa 1 MB groß ist). Die Seite enthält auch ehrliche Haftungsausschlüsse, wie die workload-spezifische Natur des Lazy-Tape-Vorteils und die grundlegende RSS-Lücke zwischen dynamischer Typisierung und typisierten Strukturen. Das Gesamtbild ist, dass Perry bei einigen Workloads mit dynamisch typisierten Laufzeiten konkurrieren kann, aber gegen SIMD-beschleunigte Parser und typisierte Deserialisierung verliert, und das Projekt ist Pre-1.0.

Redaktionelles Fazit

Die Benchmark-Seite ist ein gründlicher, selbstkritischer Vergleich, der sowohl direkte Vergleichsziele als auch Kalibrierungsziele einschließt und explizit auflistet, was nicht gemessen wird. Perry ist Pre-1.0, daher sind die Zahlen eine Momentaufnahme des aktuellen Alpha-Zustands.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes