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

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

Также проверьте ONC-RPC (старый SUN-RPC)

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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