Il existe un certain nombre de bibliothèques JSON disponibles pour Erlang, et ce n'est pas clair pour moi qui ont les meilleures caractéristiques de performance (et, secondairement la facilité d'utilisation), en particulier pour la sérialisation erlang-to-JSON.
Mon cas d'utilisation nécessite une analyse et une sérialisation JSON, mais le code Erlang produira probablement au moins deux commandes de magnitude plus de sortie JSON (c'est-à-dire la sérialisation) qu'elle ne recevra plus d'informations.
Pour référence, les bibliothèques que je connaissais incluent ce qui suit (et il peut y avoir d'autres que je n'ai pas trouvé):
4 Réponses :
Espérons que cette réponse ne sera pas mal reçue, cependant:
J'ai aussi jeté l'analyse et la sérialisation JSON pour un projet. Je devais traiter beaucoup de données en parallèle, alors erlang sonna super! Mais beaucoup de ceux qui traitaient des cordes sous la forme de données JSON, et c'est là que les choses ont été acidulées.
Comme vous savez probablement que les chaînes d'Erlang sont des listes de caractères complètes. Contrairement aux chaînes dans la plupart des langues (un caractère est "à propos de" un octet), chaque caractère d'Erlang est représenté par un entier entièrement 32 bits! Donc, déjà vos cordes sont assez grandes.
Parce que c'est une liste, l'accès à un élément donné de la chaîne est O (n) au lieu de O (1), comme vous l'attendiez dans une gamme de caractères. Et, parce que les chaînes sont immuables dans Erlang Simple Concaténation peut finir par être un processus très lent. À la fin, j'ai réalisé que j'essayais simplement d'utiliser la mauvaise langue.
Dans toutes les probabilités, vous connaissez déjà toutes ces choses, mais j'ai estimé qu'il était utile de laisser cela comme une réponse aux autres personnes qui peuvent arriver à votre poste à l'avenir.
Vous devez utiliser des fichiers binaires dans de tels cas, pas cordes.
Et vous devriez apprendre quelque chose à propos de l'encodage des chaînes Unicode, par exemple UTF-8, lorsque vous accédez à des caractères devient immédiatement O (n).
Et vous devriez examiner divers points de repère de traitement de chaînes qui montrent que l'utilisation de listes est souvent plus rapide.
J'utilise rfc4627.erl < / code> (je suis tombé dessus dessus et la performance n'a pas été un problème)
Cependant, je m'attends à ce que les différentes bibliothèques d'erlang indigènes puissent accomplir de la même manière. Ils partagent des idées (comme été témoin du Commentaires du code ). AFAIK EEP018 est C, et comme il s'efforce de mettre en œuvre ... HRM ... < un href = "http://www.erlang.org/eeps/ep-0018.html" rel = "nfollow noreferrer"> eep-0018 , le Ma dernière recommandation est allée avec comme pour choisir entre mochijson et rfc4627 Partagez le même format Source Erlang.
term_to_json codeur natif qui pourrait être inclus dans une future version d'Erlang. Jamais essayé et ne semble pas activement entretenu.
mochijson et mochijson2 , pourrait vous aider.
J'utilise JSELERL ces derniers temps. Il est basé sur Mochijson2 et est beaucoup plus facile et intuitif à utiliser.
Essayez https://github.com/si14/erl_json_test points de repère Erlang JSON. Il incluait des points de repère pour:
élément de la liste
JSONX
jiffy
mochijson2
JSX
Il y a aussi le module JSON dans les yaws.
EEP0018 est maintenant remplacé par cette lib: Github.com/davisp/jiffy