Как протокольные буферы быстрее, чем XML и JSON?

Question

Я недавно начал читать и использовать gRPC в своей работе. gRPC использует внутренние буферы протокола в качестве своей IDL, и я везде читаю, что буферы протокола работают намного лучше, особенно быстрее по сравнению с JSON и XML.

Чего я не понимаю - как они это делают? Какой дизайн буферов протокола на самом деле заставляет их работать быстрее по сравнению с XML и JSON?

Answer 1

Хотя двоичные протоколы имеют теоретическое преимущество, на практике они могут потерять производительность по сравнению с JSON или другим протоколом с текстовым представлением в зависимости от реализации.

Эффективные парсеры JSON, такие как RapidJSON или jsoniter-scala анализируют большинство выборок JSON со скоростью 2-8 циклов на байт. Они сериализуются еще более эффективно, за исключением некоторых крайних случаев, таких как числа с плавающей запятой, когда скорость сериализации может упасть до 16-32 циклов на байт.

Но для большинства доменов, у которых нет большого числа операций с плавающей запятой или удваивается, их скорость вполне конкурентоспособна с лучшими двоичными сериализаторами. Посмотрите результаты тестов, в которых jsoniter-scala анализирует и сериализует наравне с библиотеками Java и Scala для ProtoBuf:

https://github.com/dkomanov/scala-serialization/pull/8

Answer 2

Я бы сказал, что двоичные протоколы обычно всегда выигрывают в производительности по сравнению с текстовыми протоколами. Ха, вы не найдете много (или каких-либо) приложений потокового видео, использующих JSON для представления данных кадра. Однако любая плохо спроектированная структура данных будет испытывать трудности при анализе. Я работал над многими коммуникационными проектами, где текстовые протоколы были заменены «двоичными протоколами».

Answer 3

Строковые представления данных:

• требуется кодирование / декодирование текста (это может быть дешево, но все еще является дополнительным шагом)
• требует сложного кода синтаксического анализа, особенно если существуют удобные для человека правила, такие как «должны разрешать пробелы»
• обычно включает в себя большую полосу пропускания - так больше фактической полезной нагрузки для оттока - из-за встраивания таких вещей, как имена, и (опять же) необходимости иметь дело с удобными для человека представлениями (например, как разбить синтаксис на синтаксис)
• часто требует много экземпляров промежуточных строк, которые используются для поиска членов и т. Д.

Как текстовые, так и двоичные сериализаторы могут быть быстрыми и эффективными (или медленными и ужасными) ... просто: бинарные сериализаторы имеют свои преимущества. Это означает, что «хороший» двоичный сериализатор обычно будет быстрее, чем «хороший» текстовый сериализатор.

Давайте сравним базовый пример целого числа:

JSON:

{"id":42}

9 байт, если мы допустим кодировку ASCII или UTF-8 и не будет пробелов.

XML:

<id>42</id>

11 байт, если мы допустим кодировку ASCII или UTF-8 и не будем использовать пробелы - и не будем слышать шум в пространстве имен, как пространства имен.

Protobuf:

0x08 0x2a

2 байта

Теперь представьте, что вы пишете синтаксический анализатор xml или json общего назначения, а также все неоднозначности и сценарии, которые вам нужно обработать только на текстовом слое , тогда вам нужно сопоставить текстовый токен "id" с элементом , тогда вам нужно выполнить целочисленный синтаксический анализ "42". В protobuf полезная нагрузка меньше, плюс математика проста, и поиск членов является целым числом (поэтому: подходит для очень быстрого switch / прыжка).