Jak Google Protocol Buffers porównuje się do ASN.1

Question

Jakie są najbardziej zauważalne różnice między buforami protokołów Google i ASN.1 (z kodowaniem PER)? Dla mojego projektu najważniejszą kwestią jest wielkość zserializowanych danych. Czy ktoś dokonał porównań wielkości danych między tymi dwoma?

Answer 1

Minęło dużo czasu, odkąd wykonałem jakąkolwiek pracę ASN.1, ale rozmiar jest bardzo prawdopodobne, zależy od szczegółów typów i rzeczywistych danych.

Chciałbym zdecydowanie zalecamy, aby prototypować i umieścić kilka rzeczywistych danych w celu porównania.

Jeśli Twój protokół buforowy zawierałby powtarzające się typy pierwotne, powinieneś sprawdzić najnowsze źródło w Subversion dla buforów protokołów - mogą one być reprezentowane w "spakowanym" formacie, który jest znacznie bardziej wydajny. (Mój port C# ma tylko połapał się z tą funkcją, jakiś czas w zeszłym tygodniu.)

Answer 2

Jeśli używasz ASN.1 z Unaligned PER i definiujesz typy danych za pomocą odpowiednich więzów (np. Określając dolną/górną granice dla liczb całkowitych, górne granice dla długości list itd.), twoje kodowanie będzie bardzo zwarte. Nie będzie marnowanych bitów na takie rzeczy jak wyrównanie lub dopełnienie między polami, a każde pole będzie zakodowane w minimalnej liczbie bitów niezbędnych do utrzymania dopuszczalnego zakresu wartości. Na przykład pole typu INTEGER (1..8) zostanie zakodowane w 3 bitach (1 = '000', 2 = '001', ..., 8 = '111'); a wybór z czterema alternatywami zajmie 2 bity (wskazujące wybraną alternatywę) plus bity zajmowane przez wybraną alternatywę. ASN.1 ma wiele innych interesujących funkcji, które z powodzeniem zastosowano w wielu opublikowanych standardach. Przykładem jest znacznik rozszerzenia ("..."), który po zastosowaniu do SEKWENCJI, WYBORU, WYBUCHOWANEGO i innych typów umożliwia kompatybilność wsteczną i do przodu między punktami końcowymi implementującymi różne wersje specyfikacji.

Answer 3

Gdy wielkość zapakowany/zakodowany komunikat jest ważny należy również zwrócić uwagę na fakt, że protobuf nie jest w stanie zapakować repeated pola, które nie mają primitive numeric type, read this uzyskać więcej informacji.

Jest to problem, np. jeśli masz wiadomości tego typu: (komentarz określa rzeczywisty zakres wartości)

message P{ 
    required sint32 x = 1; // -0x1ffff to 0x20000 
    required sint32 y = 2; // -0x1ffff to 0x20000 
    required sint32 z = 3; // -0x319c to 0x3200 
} 
message Array{ 
    repeated P ps = 1; 
    optional uint32 somemoredata = 2; 
} 

W przypadku gdy masz długość tablicy, na przykład, 32 niż można byłoby doprowadzić zapakowany rozmiaru wiadomości od około 250 do 450 bajtów z protobuf, w zależności od wartości, które tablica zawiera. Może to nawet wzrosnąć do ponad 1000 bajtów w przypadku korzystania z pełnego zakresu 32-bitowego lub w przypadku korzystania z int32 zamiast sint32 i mieć wartości ujemne.

BLOB danych surowych (zakładając, że Z może być zdefiniowana jako int16 wartość) będzie zużywać tylko 320 bajty, a zatem ASN.1 komunikat jest zawsze mniejszy niż 320 bajty, ponieważ wartość maksymalna nie jest 32-bitowym, ale faktycznie 19bit (x, y) i 15bit (z).

buforów rozmiar wiadomości mogą być zoptymalizowane zgodnie z tą definicją wiadomości:

message Ps{ 
    repeated sint32 xs = 1 [packed=true]; 
    repeated sint32 ys = 2 [packed=true]; 
    repeated sint32 zs = 3 [packed=true]; 
} 
message Array{ 
    required Ps ps = 1; 
    optional uint32 somemoredata = 2; 
} 

co skutkuje rozmiarów wiadomości od około 100 bajtów (wszystkie wartości są zerami), 300 bajty (wartości w zakresie max) i 500 Bajt (wszystkie wartości to wysokie 32-bitowe wartości).