Quelle est la rapidité ou la légèreté de Protocol Buffer?

Question

Le tampon de protocole pour .NET sera-t-il plus léger / plus rapide que Remoting (le SerializationFormat.Binary)? Y aura-t-il un support de première classe pour cela en termes de langage / cadre? c’est-à-dire qu’elle est gérée de manière transparente comme avec Remoting / WebServices?

Answer 1

Je doute fort qu'il aura jamais un support linguistique direct ou même un support framework - c'est le genre de chose parfaitement gérée par les bibliothèques tierces.

Mon propre port du code Java est explicite - vous devez appelez des méthodes pour sérialiser / désérialiser. (Il existe des stubs RPC qui seront automatiquement sérialisés / désérialisés, mais aucune implémentation RPC pour le moment.)

Le projet de Marc Gravell s'intègre très bien dans WCF, même si, dans la mesure du possible, Sachez qu’il vous suffit de lui indiquer (une fois) d’utiliser des tampons de protocole pour la sérialisation, le reste est transparent.

En termes de rapidité, vous devriez consulter la page de référence de Marc Gravell Mon code a tendance à être légèrement plus rapide que le sien, mais les deux sont beaucoup, beaucoup plus rapides que les autres options de sérialisation / désérialisation du framework. Il convient de noter que les tampons de protocole sont également beaucoup plus limités: ils n'essayent pas de sérialiser des types arbitraires, mais uniquement ceux pris en charge. Nous allons essayer de prendre en charge davantage de types de données courants (décimal, DateTime, etc.) de manière portable (à l’aide de leurs propres messages de mémoire tampon de protocole).

Answer 2

Certaines mesures de performance et de taille se trouvent sur cette page . Je ne connais pas les statistiques de Jon pour le moment, simplement parce que la page est un peu ancienne (Jon: il faut corriger ça!).

Re être transparent; protobuf-net peut se connecter à WCF via le contrat; notez que cela fonctionne bien avec MTOM sur basic-http aussi. Cela ne fonctionne pas avec Silverlight, car Silverlight n'a pas le point d'injection. Si vous utilisez svcutil, vous devez également ajouter un attribut à class (via une classe partielle).

Re BinaryFormatter (remoting); oui, cela a un soutien complet; vous pouvez le faire simplement par une implémentation triviale ISerializable (c'est-à-dire, appelez simplement la méthode Serializer avec les mêmes arguments). Si vous utilisez protogen pour créer vos classes, il peut le faire pour vous: vous pouvez l'activer sur la ligne de commande via des arguments (il n'est pas activé par défaut en tant que BinaryFormatter ne fonctionne pas sur tous les cadres [CF, etc.].

Notez que pour les très petits objets (instances uniques, etc.) sur le remoting local (IPC), les performances brutes BinaryFormatter sont en réalité meilleures - mais pour les graphes ou liens distants non triviaux (remoting réseau) Protobuf-net peut le surpasser assez bien.

Je dois également noter que le format filaire des tampons de protocole ne prend pas directement en charge l'héritage; protobuf-net peut usurper cela (tout en conservant la compatibilité filaire), mais comme avec XmlSerializer, vous devez déclarer les sous-classes à l’avance.

Pourquoi existe-t-il deux versions?

Les joies de l'open source, je suppose ;-p Jon et moi avons déjà travaillé sur des projets communs et avons discuté de la fusion de ces deux projets, mais le fait est qu'ils visent deux scénarios différents:

• dotnet-protobufs (la version de Jon) est un portage de la version Java existante. . Cela signifie qu’elle a une API très familière pour tous ceux qui utilisent déjà la version Java et qu’elle est construite sur des constructions Java typiques (classes de constructeur, classes de données immuables, etc.) - avec quelques modifications C #.
• protobuf-net (Marc's) est une nouvelle implémentation complète suite à le même format binaire (en effet, il est essentiel de pouvoir échanger des données entre différents formats), mais en utilisant des idiomes .NET typiques:
  • classes de données mutables (pas de générateurs)
  • les spécifications du membre de sérialisation sont exprimées en attributs (comparables à XmlSerializer , DataContractSerializer , etc.)

Si vous travaillez sur des clients Java et .NET, Jon's est probablement un bon choix pour l'API familière des deux côtés. Si vous êtes pur .NET, protobuf-net présente des avantages - l’API de style .NET bien connue, mais aussi:

• vous n'êtes pas obligé d'être d'abord contractuel (bien que vous le puissiez et qu'un générateur de code est fourni)
• vous pouvez réutiliser vos objets existants (en fait, les classes [DataContract] et [XmlType] peuvent souvent être utilisées sans aucune modification)
• il prend totalement en charge l'héritage (qu'il réalise sur le réseau en encapsulant de manière abusive) (éventuellement unique pour une implémentation de tampons de protocole? notez que les sous-classes doivent être déclarées à l'avance)
• se débrouille pour exploiter et exploiter les principaux outils .NET ( BinaryFormatter , XmlSerializer , WCF, DataContractSerializer ) - permettant il fonctionne directement comme un moteur d'accès distant. Ce serait probablement une grosse séparation du tronc principal de Java pour le port de Jon.

Re les fusionnant; Je pense que nous y serions tous les deux ouverts, mais il semble peu probable que vous souhaitiez les deux ensembles de fonctionnalités, car ils répondent à des exigences aussi différentes.