Tampons de protocole versus JSON ou BSON [fermé]

90

Quelqu'un a-t-il des informations sur les caractéristiques de performance des tampons de protocole par rapport à BSON (JSON binaire) ou par rapport à JSON en général?

  • Taille de fil
  • Vitesse de sérialisation
  • Vitesse de désérialisation

Ceux-ci semblent être de bons protocoles binaires à utiliser sur HTTP. Je me demande simplement ce qui serait mieux à long terme pour un environnement C #.

Voici quelques informations que je lisais sur BSON et Protocol Buffers .

c#  json  comparison  protocol-buffers  bson 
— Jeff Meatball Yang
source
Certains soutiennent (je pense que cela inclut un ancien auteur de protobuf) que c'est une meilleure idée d'utiliser un format plus grand mais moins cher pour sérialiser et ensuite compresser la sortie avec un compresseur standard rapide.
— CodesInChaos
— laike9m
Je ne pense pas que cela devrait être rouvert jusqu'à ce qu'une certaine méthode de comparaison soit proposée dans la question elle-même (sinon c'est pour une discussion plutôt opiniâtre / trop large)
— YakovL

Réponses:

64

Thrift est également une autre alternative de type Protocol Buffers.

Il existe de bons points de repère de la communauté Java sur la sérialisation / désérialisation et la taille des fils de ces technologies: https://github.com/eishay/jvm-serializers/wiki

En général, JSON a une taille de fil légèrement plus grande et un DeSer légèrement pire, mais gagne en ubiquité et en la capacité de l'interpréter facilement sans l'IDL source. Le dernier point est quelque chose qu'Apache Avro tente de résoudre, et il bat les deux en termes de performances.

Microsoft a publié un package C # NuGet Microsoft.Hadoop.Avro .

— Michael Greene
source
1
La petite taille des messages ne se traduit pas automatiquement par une perforamnce rapide, voir cet article soa.sys-con.com/node/250512
— vtd-xml-author
1
Bon lien; la seule chose dont je ne suis pas sûr est un commentaire sur Avro - bien qu'il puisse fonctionner plus efficacement pour ses principaux cas d'utilisation (des tonnes d'entrées de données similaires), il ne semble pas fonctionner très rapidement dans ce benchmark (qui teste la manipulation d'un demande unique)
— StaxMan
CoDec, MoDem .... J'aime mieux "SeDes" :)
— nawfal
52

Voici quelques repères récents montrant les performances des sérialiseurs .NET populaires.

Les benchmarks Burning Monks montrent les performances de sérialisation d'un POCO simple tandis que les benchmarks complets Northwind montrent les résultats combinés de la sérialisation d'une ligne dans chaque table de l'ensemble de données Northwind de Microsoft.

entrez la description de l'image ici

Fondamentalement, les tampons de protocole ( protobuf-net ) sont environ 7 fois plus rapides que le sérialiseur de bibliothèque de classes de base le plus rapide dans .NET (XML DataContractSerializer). Il est également plus petit que la concurrence car il est également 2,2 fois plus petit que le format de sérialisation le plus compact de Microsofts (JsonDataContractSerializer).

Les sérialiseurs de texte de ServiceStack sont les plus proches de correspondre aux performances du binaire protobuf-net où son Json Serializer est seulement 2,58x plus lent que protobuf-net.

— Mythz
source
1
Excellent article - mais si possible, vous devez toujours mettre des barres d'erreur sur vos graphiques à barres lorsque vous affichez des moyennes.
— jtromans
Pourquoi JIL n'est-il pas inclus dans les tests? (avez-vous une idée pourquoi?)
— Royi Namir
22

les tampons de protocole sont conçus pour le fil:

  1. très petite taille de message - un aspect est la représentation d'entiers de taille variable très efficace.
  2. Décodage très rapide - c'est un protocole binaire.
  3. protobuf génère un C ++ super efficace pour encoder et décoder les messages - astuce: si vous encodez tous les var-integers ou les éléments de taille statique, il encodera et décodera à une vitesse déterministe.
  4. Il offre un modèle de données TRÈS riche - encodant efficacement des structures de données très complexes.

JSON est juste du texte et il doit être analysé . astuce: encoder un "milliard" entier dedans prendrait pas mal de caractères: Billion = 12 char's (longue échelle), en binaire il tient dans un uint32_t Maintenant qu'en est-il d'essayer d'encoder un double? ce serait bien pire.

— Hassan Syed
source
4
Cela a cependant l'inconvénient plutôt malheureux de ne pas gérer l'héritage et, bien que la composition soit une alternative valable, je préfère ne pas être forcé par mon objet de transfert de données à utiliser la composition plutôt que l'héritage.
— Mark Green
4
Je pense que les extensions peuvent être utilisées d'une manière très similaire à l'héritage ... developer.google.com/protocol-buffers/docs/reference/…
— kralyk
1
Oui, les extensions sont un très bon point. Je l'utilise quotidiennement au travail.
— Yngve Sneen Lindal
"Les tampons de protocole sont conçus pour le fil" Qu'est-ce que "le fil"?
— Marcos Pereira
@marcospgp the wiresignifie juste un réseau. Maintenant, lorsque nous utilisons autant de réseaux sans fil, cela peut sembler étrange.
— Victor Yarema le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.