Je n'ai pas comparé les Protocol Buffers avec la sérialisation native de Java en termes de vitesse, mais pour l'interopérabilité, la sérialisation native de Java est un sérieux non-non. Elle ne sera pas non plus aussi efficace en termes d'espace que Protocol Buffers dans la plupart des cas. Bien sûr, il est un peu plus flexible en termes de ce qu'il peut stocker, et en termes de références, etc. Protocol Buffers est très bon pour ce à quoi il est destiné, et quand il répond à vos besoins, il est excellent - mais il y a des restrictions évidentes dues à l'interopérabilité (et d'autres choses).
J'ai récemment publié un cadre d'évaluation des tampons de protocole en Java et .NET. La version Java est dans le principal projet Google (dans le répertoire des repères ), la version .NET est dans mon projet de portage en C# . Si vous voulez comparer la vitesse de PB avec la vitesse de sérialisation de Java, vous pouvez écrire des classes similaires et les évaluer. Cependant, si vous êtes intéressé par l'interopérabilité, je n'accorderais vraiment aucune importance à la sérialisation Java native (ou à la sérialisation binaire native de .NET).
Il existe d'autres options de sérialisation interopérable que les tampons de protocole. Économie d'argent , JSON et YAML viennent à l'esprit, et il y en a sans doute d'autres.
EDIT : Bon, l'interopérabilité n'étant pas si importante, cela vaut la peine d'essayer d'énumérer les différentes qualités que vous attendez d'un cadre de sérialisation. Une chose à laquelle vous devriez penser est le versioning - c'est une autre chose que PB est conçu pour bien gérer, à la fois vers l'arrière et vers l'avant (de sorte que les nouveaux logiciels peuvent lire les anciennes données et vice versa) - lorsque vous vous en tenez aux règles suggérées, bien sûr :)
Ayant essayé d'être prudent quant aux performances de Java par rapport à la sérialisation native, je ne serais vraiment pas surpris de constater que PB était plus rapide de toute façon. Si vous en avez l'occasion, utilisez la VM du serveur - mes récents benchmarks ont montré que la VM du serveur était plus de deux fois plus rapide à sérialiser et désérialiser les données de l'échantillon. Je pense que le code PB convient très bien au JIT de la VM du serveur :)
À titre d'exemple, la sérialisation et la désérialisation de deux messages (l'un de 228 octets, l'autre de 84750 octets) ont donné les résultats suivants sur mon ordinateur portable en utilisant la VM du serveur :
Benchmarking benchmarks.GoogleSize$SizeMessage1 with file google\_message1.dat
Serialize to byte string: 2581851 iterations in 30.16s; 18.613789MB/s
Serialize to byte array: 2583547 iterations in 29.842s; 18.824497MB/s
Serialize to memory stream: 2210320 iterations in 30.125s; 15.953759MB/s
Deserialize from byte string: 3356517 iterations in 30.088s; 24.256632MB/s
Deserialize from byte array: 3356517 iterations in 29.958s; 24.361889MB/s
Deserialize from memory stream: 2618821 iterations in 29.821s; 19.094952MB/s
Benchmarking benchmarks.GoogleSpeed$SpeedMessage1 with file google\_message1.dat
Serialize to byte string: 17068518 iterations in 29.978s; 123.802124MB/s
Serialize to byte array: 17520066 iterations in 30.043s; 126.802376MB/s
Serialize to memory stream: 7736665 iterations in 30.076s; 55.93307MB/s
Deserialize from byte string: 16123669 iterations in 30.073s; 116.57947MB/s
Deserialize from byte array: 16082453 iterations in 30.109s; 116.14243MB/s
Deserialize from memory stream: 7496968 iterations in 30.03s; 54.283176MB/s
Benchmarking benchmarks.GoogleSize$SizeMessage2 with file google\_message2.dat
Serialize to byte string: 6266 iterations in 30.034s; 16.826494MB/s
Serialize to byte array: 6246 iterations in 30.027s; 16.776697MB/s
Serialize to memory stream: 6042 iterations in 29.916s; 16.288969MB/s
Deserialize from byte string: 4675 iterations in 29.819s; 12.644595MB/s
Deserialize from byte array: 4694 iterations in 30.093s; 12.580387MB/s
Deserialize from memory stream: 4544 iterations in 29.579s; 12.389998MB/s
Benchmarking benchmarks.GoogleSpeed$SpeedMessage2 with file google\_message2.dat
Serialize to byte string: 39562 iterations in 30.055s; 106.16416MB/s
Serialize to byte array: 39715 iterations in 30.178s; 106.14035MB/s
Serialize to memory stream: 34161 iterations in 30.032s; 91.74085MB/s
Deserialize from byte string: 36934 iterations in 29.794s; 99.98019MB/s
Deserialize from byte array: 37191 iterations in 29.915s; 100.26867MB/s
Deserialize from memory stream: 36237 iterations in 29.846s; 97.92251MB/s
La différence entre "vitesse" et "taille" consiste à déterminer si le code généré est optimisé pour la vitesse ou la taille du code. (Les données sérialisées sont les mêmes dans les deux cas. La version "size" est prévue pour le cas où vous avez beaucoup de messages définis et ne voulez pas prendre beaucoup de mémoire pour le code).
Comme vous pouvez le voir, pour le plus petit message, il peut être très rapide - plus de 500 messages sérialisés ou non par milliseconde . Même avec les 87K messages, cela prend moins d'une milliseconde par message.
