Производительность сериализации в C ++

Question

Я создаю распределенное приложение C ++, которое должно выполнять сериализацию и десериализацию простых структур данных, передаваемых между различными процессами и компьютерами.

Меня не интересует сериализация сложных иерархий классов, а скорее отправка структур с несколькими простыми членами, такими как число, строки и векторы данных. Векторы данных часто могут быть много мегабайт. Я обеспокоен тем, что основанные на тексте / xml способы сделать это слишком медленно, и я действительно не хочу писать это сам, так как такие проблемы, как строковое кодирование и порядковый номер, могут сделать его намного сложнее, чем кажется на первый взгляд.

Я немного посмотрел на буферы протокола и boost.serialize. Согласно документам, буферы протокола, похоже, сильно заботятся о производительности. Boost кажется несколько более легким в том смысле, что у вас нет внешнего языка для указания формата данных, который я считаю довольно удобным для этого конкретного проекта.

Итак, мой вопрос сводится к следующему: кто-нибудь знает, быстрая ли сериализация наддува для типичного случая использования, который я описал выше?

Также, если есть другие библиотеки, которые могут подойти для этого, я был бы рад услышать о них.

Answer 1

Я бы настоятельно рекомендовал буферы протокола. Они невероятно просты в использовании, предлагают отличную производительность и заботятся о таких проблемах, как обратная последовательность и обратная совместимость. Чтобы сделать их еще более привлекательными, сериализованные данные не зависят от языка благодаря многочисленным языковым реализациям.

Answer 2

ACE и ACE TAO приходят на ум, но вам может не понравиться их размер и объем. http://www.cs.wustl.edu/~schmidt/ACE.html

Относительно вашего запроса о " быстром " и повысить. Это субъективный термин, и, не зная ваших требований (пропускная способность и т. Д.), Трудно ответить на этот вопрос для вас. Не то чтобы у меня были какие-то тесты для буста ...

Вы можете использовать слои сообщений, но они, вероятно, медленнее, чем boost. Я бы сказал, что вы определили хорошее решение для повышения, но я использовал только ACE и другие проприетарные продукты для обмена сообщениями.

Answer 3

Мое предположение заключается в том, что ускорение происходит достаточно быстро. Я использовал его в предыдущих проектах для сериализации данных на диск и с диска, и его производительность никогда не возникала.

Мой ответ здесь рассказывает о сериализации в общие сведения, которые могут оказаться полезными для вас, помимо того, какую библиотеку сериализации вы решите использовать.

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

Какой бы путь вы ни выбрали, удачи вам в вашем проекте.

Answer 4

Также ознакомьтесь с ONC-RPC (старый SUN-RPC)

Answer 5

boost.serialization не заботится о кодировках строк или порядке байтов. Вы также будете преуспевать, не используя его, если это важно для вас.

Возможно, вы захотите взглянуть на ICE из ZeroC: http://www.zeroc.com/

Он работает аналогично CORBA, за исключением того, что он полностью разработан и определен компанией. Плюс в том, что реализации работают так, как задумано, поскольку их не так много. Недостатком является то, что если вы используете язык, который они не поддерживают, вам не повезло.

Answer 6

Если вы отправляете только четко определенные структуры данных, возможно, вам следует обратиться к ASN. .1 как методология кодирования?

Answer 7

Существует также Thrift , который выглядит как альфа-проект, но используется и разрабатывается Facebook так что у него есть несколько пользователей.

Или старый добрый DCE , который был стандартным MS, который решили использовать для COM. Сейчас он с открытым исходным кодом, на 20 лет позже, но лучше, чем никогда.

Answer 8

Не оптимизируйте с преимуществом. Измерьте первое и оптимизируйте второе.