Un outil de benchmarking a été mis en ligne sur GitHub, permettant de comparer la performance de diverses implémentations de sérialisation JSON pour le langage Go. L’initiative, nommée jsonbench, permet d’évaluer différentes bibliothèques — de encoding/json standard à des solutions plus spécialisées comme SonicJSON ou SegmentJSON — sur des jeux de données variés.

Selon l’annonce de github.com, ce comparatif évalue huit implémentations distinctes. On y trouve JSONv1, la version standard, et JSONv1in2, qui réplique le comportement de l’API v1 en utilisant JSONv2. JSONv2 est une implémentation expérimentale qui vise à corriger les défauts du standard.

Les tests ont été menés sur un AMD Ryzen 9 9950X et ont utilisé six ensembles de données pour couvrir différents scénarios : du GeoJSON structuré (CanadaGeometry) aux données de santé complexes (SyntheaFHIR), en passant par des flux de statut Twitter. Les résultats montrent que, pour la sérialisation depuis des types concrets, JSONv2 se positionne entre 1,2 fois plus rapide et 1,4 fois plus lent que JSONv1, selon les cas.

Les compromis de l’implémentation v2

L’approche de JSONv2 vise une meilleure robustesse, mais cela passe par des changements sémantiques importants par rapport à l’API v1. Par exemple, lorsqu’on sérialise depuis un type concret, JSONv2 n’effectue plus le tri des clés d’un map Go, ce qui améliore la vitesse. En revanche, il vérifie systématiquement l’unicité des noms d’objets JSON, ce qui pénalise la performance.

Cependant, lorsque l’on sérialise depuis un map[string]any ou un []any, JSONv2 se révèle nettement plus rapide, atteignant jusqu’à 3,6 fois la vitesse de JSONv1. Cette accélération est notable car les alternatives, hormis JSONIterator, SonicJSON et SonnetJSON, effectuent traditionnellement un tri des clés.

JSONv2 cherche à séparer clairement la syntaxe de la sémantique, une divergence notable par rapport à l’API historique. De plus, pour garantir la correction, il effectue un shallow copy des valeurs, même si cela ralentit l’opération. La mise en œuvre de support pour des méthodes définies par l’utilisateur ajoute aussi une surcharge, car elle nécessite de maintenir un état machine.

Une course à la performance et à la correction

Certaines implémentations, comme celles qui utilisent intensivement unsafe, tendent à être plus rapides, mais au détriment de la sécurité mémoire et de la sûreté des types. SonicJSON, par exemple, utilise une compilation juste-à-temps, lui donnant un avantage notable sur des jeux de données contenant des caractères Unicode à plusieurs octets, car il ne valide pas le UTF-8.

La correction est un axe majeur de l’évolution. Les problèmes rencontrés avec l’ancienne encoding/json — comme l’acceptation de UTF-8 invalide ou de noms de membres dupliqués dans les objets JSON — ont motivé ce travail. Le fait que l’ancienne version accepte des noms dupliqués, comme l’illustre le cas CVE-2017-12635, où deux clés ‘roles’ pouvaient mener à une autorisation non désirée, souligne le besoin d’une approche plus stricte.

JSONv2 est conçu pour être plus performant sans sacrifier la justesse, mais github.com le maintient comme expérimental, signalant qu’il est sujet à des changements majeurs. Il est à noter que JSONv2 est généralement aussi rapide ou plus rapide que les alternatives.

Fiche technique

Données : NVD (NIST) et GitHub Advisory Database (CC BY 4.0, données adaptées).

Sources

• GitHub – go-json-experiment/jsonbench: JSON benchmarks to compare different Go JSON implementations, github.com
• GitHub – go-json-experiment/json: Experimental implementation of a proposed v2 encoding/json package, github.com
• A new Go API for JSON, Go, 4 novembre 2026 (contenu sous licence CC BY 4.0)
• GHSA-f3p2-qqmm-jg8f : Due to differences in the Erlang-based JSON parser and JavaScript-based JSON parser, it…, GitHub Advisory Database (CC BY 4.0)
• CVE-2017-12635, NVD (NIST)