Bufory protokołów a JSON lub BSON [zamknięte]

91

Czy ktoś ma jakieś informacje na temat charakterystyk wydajności buforów protokołów w porównaniu z BSON (binarne JSON) lub ogólnie w porównaniu z JSON?

  • Rozmiar przewodu
  • Szybkość serializacji
  • Szybkość deserializacji

Wydaje się, że są to dobre protokoły binarne do użytku przez HTTP. Zastanawiam się tylko, co byłoby lepsze na dłuższą metę dla środowiska C #.

Oto kilka informacji, które czytałem na temat BSON i buforów protokołów .

c# json comparison protocol-buffers bson Jeff Meatball Yang
źródło
Niektórzy twierdzą (myślę, że obejmuje to byłego autora protobuf), że lepszym pomysłem jest użycie większego, ale tańszego formatu do serializacji, a następnie skompresowanie wyjścia za pomocą szybkiego standardowego kompresora.
CodesInChaos
devblog.corditestudios.com/blog/2012/10/29/…
laike9m
Nie sądzę, aby było to ponownie otwierane, dopóki w samym pytaniu nie zostanie zaproponowana pewna metoda porównania (w przeciwnym razie jest to raczej uparta dyskusja / zbyt szeroka)
JakowL

Odpowiedzi:

65

Oszczędność jest również inną alternatywą podobną do buforów protokołów.

Społeczność Java opracowała dobre testy porównawcze dotyczące serializacji / deserializacji i rozmiaru przewodów tych technologii: https://github.com/eishay/jvm-serializers/wiki

Ogólnie rzecz biorąc, JSON ma nieco większy rozmiar drutu i nieco gorszy DeSer, ale wygrywa w wszechobecności i możliwości łatwej interpretacji bez źródła IDL. Ostatnia kwestia to coś, co Apache Avro próbuje rozwiązać i bije oba pod względem wydajności.

Firma Microsoft wydała pakiet NuGet dla języka C # Microsoft.Hadoop.Avro .

Michael Greene
źródło
1
Mały rozmiar wiadomości nie przekłada się automatycznie na szybką wydajność, zobacz ten artykuł soa.sys-con.com/node/250512
vtd-xml-author
1
Dobry link; jedyne, czego nie jestem pewien, to komentarz na temat Avro - chociaż mógłby działać wydajniej w swoich podstawowych przypadkach użycia (tony podobnych wpisów danych), nie wydaje się działać bardzo szybko w tym benchmarku (który testuje obsługę pojedyncze żądanie)
StaxMan
CoDec, MoDem .... Bardziej lubię "SeDes" :)
nawfal
52

Oto kilka ostatnich testów porównawczych pokazujących wydajność popularnych serializatorów .NET.

Te odniesienia Spalanie Zakonnicy wykazują działanie szeregowania prosty poco podczas gdy kompleksowe Northwind benchmarki pokazują, połączonych wyników szeregowania wiersz w każdym zbiorze tabeli Northwind Microsoft.

wprowadź opis obrazu tutaj

Zasadniczo bufory protokołów ( protobuf-net ) są około 7x szybsze niż najszybszy Serializer biblioteki klasy bazowej w .NET (XML DataContractSerializer). Jest również mniejszy od konkurencji, ponieważ jest 2,2 razy mniejszy niż najbardziej kompaktowy format serializacji Microsoftu (JsonDataContractSerializer).

Serializatory tekstu usługi ServiceStack są najbardziej zbliżone do wydajności binarnej protobuf-net, w której jej serializator Json jest tylko 2,58 razy wolniejszy niż protobuf-net.

mit
źródło
1
Świetny post - ale jeśli to możliwe, podczas wyświetlania średnich zawsze należy umieszczać słupki błędów na wykresach słupkowych.
jtromans
Dlaczego JIL nie jest uwzględniony w testach? (czy wiesz dlaczego?)
Royi Namir
23

bufory protokołów są przeznaczone dla przewodów:

  1. bardzo mały rozmiar wiadomości - jednym z aspektów jest bardzo wydajna reprezentacja liczb całkowitych o zmiennej wielkości.
  2. Bardzo szybkie dekodowanie - jest to protokół binarny.
  3. protobuf generuje super wydajne C ++ do kodowania i dekodowania wiadomości - wskazówka: jeśli zakodujesz w nim wszystkie zmienne całkowite lub elementy o statycznym rozmiarze, zakoduje i zdekoduje z deterministyczną prędkością.
  4. Oferuje BARDZO bogaty model danych - wydajnie koduje bardzo złożone struktury danych.

JSON to tylko tekst i należy go przeanalizować . wskazówka: zakodowanie „miliarda” int w to zajmie całkiem sporo znaków: Miliard = 12 znaków (długa skala), binarnie mieści się w uint32_t A co z próbą zakodowania double? to byłoby O DUŻO gorsze.

Hassan Syed
źródło
4
Ma to jednak raczej niefortunną wadę polegającą na tym, że nie obsługuje dziedziczenia i chociaż kompozycja jest ważną alternatywą, wolę nie być zmuszanym przez mój obiekt przesyłania danych do używania kompozycji, a nie dziedziczenia.
Mark Green
4
Uważam, że rozszerzenia mogą być używane w sposób bardzo podobny do dziedziczenia ... developers.google.com/protocol-buffers/docs/reference/…
kralyk
1
Tak, rozszerzenia to bardzo dobra uwaga. Używam go w praktyce na co dzień w pracy.
Yngve Sneen Lindal,
„bufory protokołów są zaprojektowane dla przewodu” Co to jest „przewód”?
Marcos Pereira
@marcospgp the wireoznacza tylko sieć. Teraz, kiedy używamy tak wielu sieci bezprzewodowych, może to zabrzmieć dziwnie.
Victor Yarema,