Search
Write a publication
Pull to refresh

Comments 21

Для javascript решения пока нет. IMHO наличие такого решения, возможно, могло увеличить интерес к этому формату

Cap'n proto не рассматривали? Вроде бы от одного из авторов Protobuf. Как работа над ошибками. Позиционируется как самый быстрый сериализатор.

Быстрее flatbuffers от того же гугла?

Возможно или сопоставим. Пошёл почитать, пишут что у них нет стадии сериализации/десериализации.

Внутри команды рассматривали flatbuffers. Он действительно самый быстрый, как пишет ErgoZru, но и достаточно сыроват/нестабилен для комбинации flatbuffers + gRPC. Поэтому пока следим за развитием.

Очень странное сравнение... Сравнивать protobuf, который является IDL, то есть просто описанием структур и методов, и конкретные сериализаторы... Эта статья выглядит по сути как сравнение инструкции (protobuf) по которой собирают машину и гаечных ключей, которыми собирают ту же машину. Короче теплое с мягким. Ну и никто не мешает написать ген-плагин к протобафу для перегонки прото файлов в те же MsgPack методы и структуры. Да можно даже готовые взять, тот же генератор документации и подсунуть нужный шаблон, или gotemplate генератор, и подсунуть полноценный шаблон и генерировать вообще что хочешь. Да и gob прикрутить при желании можно. Ч не говорю о совместимости с протобафом в котором есть своя реализация, но дополнить ее никто не мешает.

Всё верно, сравнение не совсем "нормально" с математической точки зрения. Но мы живём не в идеальном мире: любые решения будут иметь свои наборы свойств и особенностей, которые нельзя будет привести к общему знаменателю.
Статья разбирает решения не только с технической точки зрения, но и со стороны эксплуатации/разработки ("административная" стороны медали).

Можно и реализовать своё решение со схемами, дебагом и сусликами, которое будет соответствовать всем требованиям. Но такое решение будет технико-экономически неконкурентоспособно, так как на него нужно ещё до начала эксплуатации затратит много человекочасов и не факт, что результат будет лучше.

Это скорее сравнение разных подходов, с одной стороны Protobuf с подходом к кросплатформенности и кодогенерацией со стороны документации к коду. И messagepack c gob, как вариант для ситуаций когда мы движемся от кода к документации. Так же хорошо прослеживается что автор намекает на то что все 3 варианта могли бы быть популярны при наличии заинтересованной компании в виде пиара и разработчиков.

Да, хорошо подмечено: proto - это schema-first решение, msgpack и gob - это всё таки code-first решение.

Еще один аргумент в пользу protobuf - его знает большинство разработчиков и не будет тратиться время на обучение вновь пришедших в команду.

Жду вторую часть с конкретными цифрами, ибо при выборе решения важно опираться на такие показатели, как размер сообщения, нагрузка на проц при кодировке/раскодировке и потребление памяти при этом.

Это второе решение после JSON, которое не требует отдельного изучения для вновь пришедших в команду. Это серьёзное преимущество для коммерческой разработки.

Вторая часть уже почти готова. Не стал делать long-long-story. Тем более теперь появились новые мысли, что нужно бы добавить/доправить, чтобы цифры были интереснее.

Вы тут пишите в комментариях про технико-экономическое обоснование (про конкурентность решений). Экономическое - вижу, хотя и без ваших человекочасов. А где технические цифры? Можно же сравнить их по производительности, компактности, сколько ресурсов жрут, что там аллокациями. Было бы вообще неплохо сравнить с JSON (мне кажется, его куда чаще используют).

Как писал уже выше, вторая часть будет чуть позже.
Спасибо про аллокации, я их не сравнивал, добавлю в следующей части.

Занудство мод on: пакет json от goccy все ещё работает быстрее существующих реализаций msgpack и gob на кодировании и декодировании, с protobuf не сравнивал. Так что если сетевые издержки не являются узким местом - звучит будто их использование - пустая трата времени в текущих реалиях.

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

Весьма кстати статья. Как раз искал готовое решение для UNIX RPC сокетов, для обмена между двумя процессами и Gob пока подходит.

Жаль что статью заминусовали.

Sign up to leave a comment.