Сравнение форматов сериализации

[@martyncev]

Я бы еще добавил в тестирование Kryo и реализацию сериализации от Одноклассников.

[@sena]

Выбор формата — это компромисс между скоростью сериализации и размером выходных данных. В то же время, не стоит забывать о таких важных параметрах как удобство использования формата и возможность эволюции схемы (часто эти параметры играют доминирующую роль).

Второе предложение противоречит первому :)
Конечно же, есть и другие параметры, которые могут быть определяющими. Вот какие приходят в голову

• Прямая и обратная совместимость
• Распространённость/популярность
• Наличие стандарта
• Удобство, простота использования. Причём здесь можно выделить
  
  • Удобство самого формата (например текстовый удобней при отладке и диагностике)
  • Удобство библиотеки сериализации
• Поддержка различных структур и типов данных (возможны существенные для проекта ограничения)
• Перспективы существования и развития формата и поддерживающих библиотек
• Открытость и независимость (не всегда открытость => независимость) формата и поддерживающих библиотек

Каждый из этих пунктов можно развернуть в объёмный текст.

[@Gr1f0n]

Да, вы правы, не совсем корректно выразился :)
Мне не хотелось быть категоричным и утверждать, что размер упакованных данных и скорость их упаковки являются единственными важными параметрами, поэтому назвал то, что приходилось учитывать в своей практике. Однако, как вы верно заметили, есть еще множество других немаловажных параметров.

[@Taraflex]

Добавлю один немаловажный пункт, который зачастую ненужен изначально, но может потребоваться при дальнейшем развитии

— Ссылки
— Циклические ссылки

[@sena]

Это можно отнести к пункту «различные структуры и типы данных».

[@andreymal]

Что насчёт CBOR? Он в RFC всё-таки.

[@vintage]

И tree, который компактней, быстрее и наглядней, чем JSON.

[@Gr1f0n]

Как-то упустил из виду. Результаты такие получились:

  Mixed data: ser.: 1279.73 ms; deser. 262.50 ms; size: 23 mb
  Only strings: ser.: 2087.63 ms; deser: 472.31 ms; size: 75 mb
  Only longs: ser.: 924.74 ms; deser.: 144.96 ms; size: 11 mb

Использовалась эта библиотека: https://github.com/sirthias/borer

Если же определить вручную encoder/decoder, то результаты по объему сериализованных данных следующие:

  Mixed data:  21 mb
  Only strings: 73 mb
  Only longs: 9,9 mb

[@pda0]

Меня вот немного раздражает, что какой-бы формат сериализации не придумывали — везде пихают сетевой порядок байт, хотя big-endian машины фактически мертвы. Разве что у Avro в спецификации есть упоминания о little-endian.

[@Mingun]

Вероятно, что чтобы проще было делать потоковую сериализацию и десериализацию

[@pda0]

В смысле — проще? Чем вам поможет, если ваш long будет в BE? Вам всё равно придётся вычитать все его байты, а потом развернуть. Разве что некий супергипотетический случай, при котором нам при поточном разборе формата будет полезно фильтровать значения по максимальным/минимальным. Тут можно начинать сравнение сразу. Только вот я не представляю такого сценария и какой-то заметной выгоды.

[@amarao]

На будущее: указывайте язык в самом начале.

[@KvanTTT]

А лучше указывать хаб этого языка.