сериализация повышения по сравнению с буферами протокола Google? [закрытый]
Я обнаружил, что несовместимость API с Python 2.7 против simplejson 3.3.1 заключается в том, генерирует ли выходные данные объекты str или unicode. например,
>>> from json import JSONDecoder
>>> jd = JSONDecoder()
>>> jd.decode("""{ "a":"b" }""")
{u'a': u'b'}
против
>>> from simplejson import JSONDecoder
>>> jd = JSONDecoder()
>>> jd.decode("""{ "a":"b" }""")
{'a': 'b'}
Если предпочтение состоит в том, чтобы использовать simplejson, то это можно устранить путем приведения строки аргумента к юникоду, например:
>>> from simplejson import JSONDecoder
>>> jd = JSONDecoder()
>>> jd.decode(unicode("""{ "a":"b" }""", "utf-8"))
{u'a': u'b'}
Принуждение требует знания оригинальной кодировки, например:
>>> jd.decode(unicode("""{ "a": "ξηθννββωφρες" }"""))
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'ascii' codec can't decode byte 0xce in position 8: ordinal not in range(128)
Это не решит выпуск 40
7 ответов
Я немного поигрался с обеими системами, ничего серьезного, просто некоторые простые хакерские штуки, но я почувствовал, что есть реальная разница в том, как вы должны использовать библиотеки.
С boost :: serialization вы сначала пишете свои собственные структуры / классы, а затем добавляете методы архивирования, но у вас все еще остаются довольно «тонкие» классы, которые можно использовать в качестве членов данных, унаследованных и т. Д.
С буферами протоколов объем кода, сгенерированного даже для простой структуры, довольно значительный, а сгенерированные структуры и код больше предназначены для работы, и что вы используете функциональность буферов протокола для передачи данных в и из вашего собственные внутренние конструкции.
У меня нет опыта ускоренной сериализации, но я использовал буферы протокола. Мне очень нравятся буферы протоколов. Имейте в виду следующее (я говорю это, не зная ускорения).
- Буферы протокола очень эффективны, поэтому я не представляю , что это серьезная проблема по сравнению с ускорением. .
- Буферы протоколов обеспечивают промежуточное представление, которое работает с другими языками (Python и Java ... и другие в разработке). Если вы знаете, что используете только C ++, может быть, boost лучше, но возможность использовать другие языки - это хорошо.
- Буферы протокола больше похожи на контейнеры данных ... здесь нет объектно-ориентированного характера, такого как наследование. Подумайте о структуре того, что вы хотите сериализовать.
- Буферы протокола гибки, потому что вы можете добавлять «необязательные» поля.
boost .serialization просто требует компилятора C ++ и дает вам синтаксический сахар, например
serialize_obj >> archive;
// ...
unserialize_obj << archive;
, для сохранения и загрузки. Если C ++ - единственный язык, который вы используете, вам следует серьезно подойти к boost.serialization.
Я бегло просмотрел буферы протокола Google. Из того, что я вижу, я бы сказал, что это напрямую не сопоставимо с boost.serialization. Вы должны добавить компилятор для файлов .proto в свою цепочку инструментов и поддерживать сами файлы .proto. API не интегрируется в C ++, как это делает boost.serialization.
boost.serialization отлично справляется со своей задачей: сериализовать объекты C ++ :) OTOH API запросов, такой как буферы протокола Google, дает вам больше гибкости.
Поскольку я пока использовал только boost.serialization, я не могу комментировать сравнение производительности.
Я никогда ничего не реализовывал с использованием библиотеки boost, но обнаружил, что protobuff Google более продуман, а код намного чище и легче читается. Я бы посоветовал взглянуть на различные языки, на которых вы хотите его использовать, прочитать код и документацию и принять решение.
Единственная трудность, с которой я столкнулся с protobufs, заключалась в том, что они назвали очень часто используемую функцию в их сгенерированном коде GetMessage (), который, конечно, конфликтует с макросом Win32 GetMessage.
Я по-прежнему очень рекомендую protobufs. Они очень полезны.
Я давно использую Boost Serialization и просто копался в буферах протоколов, и я думаю, что они не имеют той же цели. BS (не ожидал этого) сохраняет ваши объекты C ++ в поток, тогда как PB - это формат обмена, который вы читаете в / из.
Модель данных PB намного проще: вы получаете всевозможные целые и плавающие числа, строки, массивы, базовую структуру и все такое. BS позволяет напрямую сохранять все ваши объекты за один шаг.
Это означает, что с BS вы получаете больше данных по сети, но вам не нужно перестраивать всю структуру ваших объектов, тогда как буферы протокола более компактны, но после чтения архива необходимо выполнить больше работы. Как следует из названия, один предназначен для протоколов (не зависящий от языка, эффективная передача данных), другой - для сериализации (сохранение простых объектов).
Так что для вас важнее: скорость / экономия места или чистый код?
Исправление к приведенному выше (предполагаю, что это , который отвечает ) о повышении сериализации:
Это ДЕЙСТВИТЕЛЬНО позволяет поддерживать управление версиями данных .
Если нужно сжатие - используйте сжатый поток.
Может обрабатывать обратный обмен между платформами, поскольку кодировка может быть текстовой, двоичной или XML.
Boost Serialization
- - это библиотека для записи данных в поток.
- не сжимает данные.
- не поддерживает автоматическое управление версиями данных.
- поддерживает контейнеры STL.
- свойства записываемых данных зависят от выбранных потоков (например, порядок байтов, сжатие).
Protocol Buffers
- генерирует код из описания интерфейса (по умолчанию поддерживает C ++, Python и Java. C, C # и другие сторонние).
- необязательно сжимает данные.
- автоматически обрабатывает версии данных.
- обрабатывает обратный обмен между платформами.
- не поддерживает контейнеры STL.
Boost serialization - это библиотека для преобразования объекта в сериализованный поток данных. Буферы протокола делают то же самое, но также выполняют другую работу за вас (например, управление версиями и обратный порядок байтов). Повышение сериализации проще для «небольших простых задач». Буферы протокола, вероятно, лучше подходят для «более крупной инфраструктуры».
РЕДАКТИРОВАТЬ: 24-11-10: Добавлено "автоматически" в управление версиями BS.