Perry compile du TypeScript en exécutables natifs grâce à Rust, SWC et LLVM

Aperçu du projet et rôle de la page de benchmarks : perry

Perry compile du TypeScript en exécutables natifs grâce à Rust, SWC et LLVM.

Perry est un compilateur TypeScript natif écrit en Rust. Selon la description du dépôt, il compile TypeScript directement en exécutables en utilisant SWC et LLVM. Le README situé dans benchmarks/README.md n'est pas la documentation principale du projet mais une page de benchmarks dédiée. Elle compare Perry aux pairs d'exécution Node et Bun, à un pair TS-vers-natif AssemblyScript avec json-as, et à des points de référence dans des langages compilés incluant Rust, Go, C++, Swift, Java, Kotlin et Python. Les compilateurs natifs ne sont pas traités comme des pairs mais comme un étalonnage pour montrer un plancher pour du code écrit à la main, typé statiquement et compilé à l'avance. La page est conçue pour les sceptiques, avec chaque implémentation, drapeau et décision méthodologique exposés.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 1 pour perry.

Méthodologie des benchmarks : perry

La page de benchmarks documente sa méthodologie en détail. Le matériel est un Apple M1 Max avec 64 Go de RAM sous macOS 26.4. La dernière actualisation date du 14 mai 2026, version v0.5.908. Chaque cellule est exécutée 11 fois et rapporte la médiane, p95, l'écart type de population, le min et le max, plutôt que le meilleur parmi N. Le pinning CPU utilise un indice d'ordonnanceur sur macOS et un pinning strict via taskset sur Linux. Il y a une réserve pré-1.0 : Perry est à v0.5.908, donc les chiffres peuvent régresser entre les versions. La page explique aussi une asymétrie intentionnelle : Node exécute des fichiers .mjs précompilés (types supprimés par esbuild ou tsc dans une étape de configuration non mesurée), tandis que Bun exécute directement le code source TypeScript, car l'exécution directe de TypeScript est le format d'entrée natif de Bun.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 2 pour perry.

Benchmarks JSON : lazy tape et ses limites : perry

Deux charges de travail JSON sont centrales : valider-et-aller-retour (parser puis stringifier sans toucher aux valeurs parsées) et parser-et-itérer (parser, sommer un champ de chaque enregistrement, puis stringifier). Le lazy tape de Perry, introduit dans v0.5.204, construit un ruban de 12 octets par valeur au lieu d'un arbre matérialisé, et peut copier le blob original via memcpy pour la stringification sur des parses non modifiés, similaire à la vue raw_json de simdjson. Sur valider-et-aller-retour, Perry est le plus rapide parmi les exécutions typées dynamiquement avec une médiane de 83 ms, contre 249 ms pour Bun et 377 ms pour Node, mais simdjson mène à 24 ms. Sur parser-et-itérer, où le ruban doit être matérialisé, la valeur par défaut de Perry est 425 ms, plus lente que sa propre trappe de secours mark-sweep (338 ms) et plus lente que Rust serde_json (182 ms) et Bun (251 ms). La page documente également une régression RSS (problème #745) partiellement corrigée dans v0.5.900, mais Perry a toujours environ 2,5 à 3 fois le RSS de sa propre ligne de base antérieure.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 3 pour perry.

Micro-benchmarks de calcul et drapeau fast-math : perry

Les micro-benchmarks de calcul couvrent fibonacci, loop_data_dependent, object_create, nested_loops, et cinq sondes d'optimisation : loop_overhead, math_intensive, accumulate, array_read et array_write. Fast-math est optionnel via le drapeau --fast-math, la variable d'environnement PERRY_FAST_MATH ou un paramètre package.json. Il active les drapeaux LLVM reassoc et contract par instruction sur les opérations f64. Par défaut, Perry produit une sortie f64 bit-exacte avec Node. Sur loop_overhead, Perry est à 97 ms par défaut et chute à 12 ms avec fast-math, correspondant à C++ avec -ffast-math. Cependant, loop_data_dependent, qui a une chaîne de dépendance séquentielle, n'est pas affecté : Perry est à 225 ms avec ou sans fast-math. La page souligne que ce sont des sondes de drapeaux de compilateur, pas des comparaisons de performance d'exécution, et que l'accélération de 8x sur loop_overhead est réelle mais ne s'applique qu'à ce motif spécifique d'accumulateur repliable.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 4 pour perry.

Tests de stabilité mémoire et GC : perry

La page inclut six tests mémoire et GC, chacun exécuté sous trois combinaisons de modes GC (défaut, trappe de secours mark-sweep, et gen-gc avec barrières d'écriture), soit 18 exécutions par invocation CI. Les 18 cellules passent sur le commit actuel. Les tests sont conçus pour détecter des modèles de fuite spécifiques, tels que le blocage de blocs, les fuites de cache sparse et la rétention d'environnements de fermeture. Par exemple, test_memory_json_churn est passé de 115 Mo à 91 Mo lorsque le GC générationnel est devenu la valeur par défaut dans v0.5.237. La page montre également un tableau RSS historique pour bench_json_roundtrip, incluant la régression et la correction partielle.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 5 pour perry.

Ce que la page ne mesure pas : perry

Le README liste explicitement ce que les benchmarks ne couvrent pas : la latence GC et la latence de queue, le comportement de préchauffage JIT (des itérations de préchauffage sont exécutées mais le vrai démarrage à froid n'est pas rapporté), async/await, tout I/O, les charges de travail applicatives réalistes, la pression mémoire sous contention, et le temps de compilation ou la taille binaire au-delà d'une mention que hello world fait environ 1 Mo. La page inclut également des avertissements honnêtes, tels que la nature spécifique à la charge de travail de l'avantage du lazy tape et l'écart RSS fondamental entre le typage dynamique et les structures typées. Le tableau d'ensemble est que Perry est compétitif avec les exécutions typées dynamiquement sur certaines charges de travail mais perd face aux parseurs accélérés par SIMD et à la désérialisation typée, et le projet est en pré-1.0.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 6 pour perry.

Conclusion éditoriale

Le projet intéresse les équipes qui veulent conserver TypeScript tout en livrant un binaire autonome, à condition de vérifier la compatibilité réelle de leurs dépendances Node. La première vérification doit porter sur les éléments propres à perry, notamment les commandes, fichiers et limites cités par son README.

Sources officielles

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