Quand on veut parser des JSON représentant un arbre de grande profondeur ou un grand volume de données, on ne veut, à priori, pas tout charger en mémoire, parce qu'on sait qu'à un moment ou à un autre, ça va aboutir à des problèmes de mémoire, quelque soit la manière dont on implémente le parseur (ou alors il s'agit probablement d'un autre souci d'organisation des données, comme évoqué plus haut).
Qu'on déteste XML ou pas, il faut savoir qu'on a très vite rencontré le même souci en XML. Quand on parse du XML, on ne veut pas toujours une représentation en mémoire du document complet (c'est à dire avoir un DOM). On veut simplement pouvoir lire le XML, pour en extraire des données (et pas forcément toutes) et faire des traitements ou les stocker quelque part, au fur et à mesure de la lecture du XML. En clair, avoir comme objectif technique, une occupation mémoire de complexité O(1).
C'est pourquoi il a été inventé le parser SAX, qui permet de lire le XML de manière séquentielle, et donc de traiter les données de manière séquentielle. C'est un parser "bas niveau", en ce sens qu'il ne fait pas de représentation mémoire de ce qu'il lit. Il détecte et renvoi juste chaque token du format. Une sorte de parser qui fait du streaming. À noter d'ailleurs que bon nombre de parser DOM se basent sur un parser SAX...
Bref, la plupart des parsers JSON auxquels tu penses sont des équivalents des parser DOM pour XML. Ils ne sont pas du tout mauvais. Ils ne sont juste pas adaptés à des cas d'utilisation comme le tient. Ce que tu voudrais c'est plutôt un parser JSON de plus bas niveau, comme les parsers SAX pour XML. Une petite recherche sur le web (ex: "SAX for JSON") te renverra quelques projets en ce sens ;-)
D'ailleurs y a des projets du même type pour YAML et certainement d'autres formats de données...
# Non, ils ne sont pas mauvais
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Tous les parsers JSON sont mauvais. Évalué à 10.
Quand on veut parser des JSON représentant un arbre de grande profondeur ou un grand volume de données, on ne veut, à priori, pas tout charger en mémoire, parce qu'on sait qu'à un moment ou à un autre, ça va aboutir à des problèmes de mémoire, quelque soit la manière dont on implémente le parseur (ou alors il s'agit probablement d'un autre souci d'organisation des données, comme évoqué plus haut).
Qu'on déteste XML ou pas, il faut savoir qu'on a très vite rencontré le même souci en XML. Quand on parse du XML, on ne veut pas toujours une représentation en mémoire du document complet (c'est à dire avoir un DOM). On veut simplement pouvoir lire le XML, pour en extraire des données (et pas forcément toutes) et faire des traitements ou les stocker quelque part, au fur et à mesure de la lecture du XML. En clair, avoir comme objectif technique, une occupation mémoire de complexité O(1).
C'est pourquoi il a été inventé le parser SAX, qui permet de lire le XML de manière séquentielle, et donc de traiter les données de manière séquentielle. C'est un parser "bas niveau", en ce sens qu'il ne fait pas de représentation mémoire de ce qu'il lit. Il détecte et renvoi juste chaque token du format. Une sorte de parser qui fait du streaming. À noter d'ailleurs que bon nombre de parser DOM se basent sur un parser SAX...
Bref, la plupart des parsers JSON auxquels tu penses sont des équivalents des parser DOM pour XML. Ils ne sont pas du tout mauvais. Ils ne sont juste pas adaptés à des cas d'utilisation comme le tient. Ce que tu voudrais c'est plutôt un parser JSON de plus bas niveau, comme les parsers SAX pour XML. Une petite recherche sur le web (ex: "SAX for JSON") te renverra quelques projets en ce sens ;-)
D'ailleurs y a des projets du même type pour YAML et certainement d'autres formats de données...