On Apr 8, 10:15 pm, Kenton Varda <ken...@google.com> wrote: > OK, well, I call that "compression". Try gzipping the final protobuf and FI > documents and comparing the compressed sizes. The protobuf will probably > compress better, so I'd expect the final results to be roughly even.
The redundancy elimination mechanism of FI is actually a vocabulary and it works differently than compression algorithms do. FI documents are good candidates for compression irrespective of whether a vocabulary is used or not. We've done a few tests with medium/large- sized documents and protobuf wasn't more compact than FI. Using FI as a WCF message encoding will typically return better compactness than the one reported by FI Converter. In FI Converter there is no awareness of the data types used in the original document being converted so everything is always encoded as literal. However, when FI is used as a WCF message encoding then it is data type aware and so it chooses the representation that's most appropriate for returning the highest compactness for each single value. FI supports binary, literal and restricted alphabet representations; when binary is used FI can downgrade to a smaller range; and the vocabulary can be employed to eliminate repetitions of the same values. I hope this explains how it is possible that Shirish might have better compactness with FI. But also I accept that there are circumstances, especially with very small messages, in which protobuf might have the upper hand. Alexander --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
