Czy ktoś ma jakiekolwiek informacje na temat charakterystyki wydajnościowej Buforów protokołów względem BSON (binarny JSON) lub ogólnie JSON?Bufory protokołów a JSON lub BSON
To wydaje się dobre protokołów binarnych do wykorzystania przez HTTP. Zastanawiam się, który byłby lepszy na dłuższą metę dla środowiska C#.
Oto niektóre informacje, które czytałem na temat BSON i Protocol Buffers.
Thrift to kolejna alternatywa podobna do buforów protokołu.
Istnieją dobre odniesienia ze społeczności Java na serializacji/deserializacji i rozmiaru drutu tych technologii: http://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
W ogóle, JSON ma nieco większy rozmiar drutu i nieco gorszą deser, ale wygrywa w wszechobecności i zdolność do zinterpretuj to łatwo bez IDL źródła. Ostatnia kwestia to coś, co próbuje rozwiązać Apache Avro i bije zarówno pod względem wydajności.
Firma Microsoft wydała pakiet C# NuGet Microsoft.Hadoop.Avro.
Mały rozmiar wiadomości nie przekłada się automatycznie na szybką perforację, zobacz ten artykuł http://soa.sys-con.com/node/250512 –
Dobry link; jedyną rzeczą, której nie jestem pewien, jest komentarz do Avro - podczas gdy mógłby wydajniej pracować dla swoich podstawowych przypadków użycia (ton podobnych wpisów danych), nie wydaje się, aby działał bardzo szybko w tym benchmarku (który testuje obsługę pojedyncza prośba) – StaxMan
CoDec, MoDem .... Ja lubię "SeDes" lepiej :) – nawfal
bufory protokół jest przeznaczony do Drut
JSON jest po prostu tekstem i musi być zanalizowany. podpowiedź: kodowanie int do "miliarda" wymagałoby sporo znaków: Billion = 12 znaków (długa skala), w formacie binarnym pasuje do uint32_t. A co z próbą zakodowania double? to byłoby DUŻO DUŻE.
Ma jednak dość niefortunną wadę nietraktowania dziedziczenia i podczas gdy kompozycja jest poprawna alternatywnie, wolę, aby mój obiekt przesyłania danych nie był zmuszany do używania kompozycji, a nie dziedziczenia. –
Wierzę, że rozszerzenia mogą być używane w sposób bardzo podobny do dziedziczenia ... https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#extension – kralyk
Tak, rozszerzenia są bardzo dobrym punktem. Używam go w praktyce w pracy każdego dnia. –
This post porównuje prędkości i rozmiary serializacji w .NET, w tym JSON, BSON i XML.
http://james.newtonking.com/archive/2010/01/01/net-serialization-performance-comparison.aspx
Oto some recent benchmarks pokazujący działanie popularnych .NET Serializers.
The Burning Monks benchmarks pokazują wydajność serializacji prostych POCO, podczas gdy kompleksowe Northwind benchmarks pokazują połączone wyniki serializacji wiersza w każdej tabeli zestawu danych Northwind firmy Microsoft.
Zasadniczo bufory Protocol (protobuf-net) wynosi około 7x szybciej niż najszybsze klasy bazowej biblioteki Serializatora w .NET (XML DataContractSerializer). Jest także mniejszy niż konkurencja, ponieważ jest również mniejszy niż najbardziej kompaktowy format serializacji Microsoftu (JsonDataContractSerializer) firmy Microsoft.
ServiceStack za serializers tekstowe są najbliżej dopasowanie wydajności binarnym protobuf netto gdzie jego Json Serializer jest tylko 2.58x wolniej niż protobuf netto.
Świetny post - ale jeśli to możliwe, zawsze powinieneś umieszczać paski błędów na wykresach słupkowych, pokazując średnie. – jtromans
Dlaczego JIL nie jest uwzględniony w testach? (czy masz jakiś pomysł dlaczego?) –
Niektórzy twierdzą (myślę, że obejmuje to byłego autora protobuf), że lepiej jest użyć formatu większego, ale tańszego do serializowania, a następnie skompresować wyjście za pomocą standardowego kompresora. – CodesInChaos
http://devblog.corditestudios.com/blog/2012/10/29/bson-vs-yaml-vs-protobuf/ – laike9m