Насколько быстр и легок протокольный буфер?

Question

Будет ли протокольный буфер для .NET более легким/быстрым, чем удаленное взаимодействие (SerializationFormat.Binary)?Будет ли для него первоклассная поддержка с точки зрения языка/фреймворка?то естьобрабатывается ли это прозрачно, как в случае с Remoting/WebServices?

Answer 1

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

Мой собственный порт кода Java является явным - вам необходимо вызовите методы для сериализации / десериализации. (Существуют заглушки RPC, которые автоматически сериализуют / десериализуют, но пока нет реализации RPC.)

проект Марка Гравелла очень хорошо вписывается в WCF - насколько я Знаю, вам просто нужно сказать (один раз) использовать буферы протокола для сериализации, а остальное прозрачно.

С точки зрения скорости вы должны взглянуть на эталонную страницу Марка Грэйвелла . Мой код имеет тенденцию быть немного быстрее, чем его, но оба намного, намного быстрее, чем другие варианты сериализации / десериализации в платформе. Следует отметить, что буферы протокола также намного более ограничены - они не пытаются сериализовать произвольные типы, только поддерживаемые. В будущем мы попытаемся поддерживать более распространенные типы данных (десятичные, DateTime и т. Д.) Портативным способом (в качестве собственных сообщений буфера протокола).

Answer 2

Некоторые показатели производительности и размера включены. эта страница.На данный момент у меня там нет статистики Джона, просто потому, что страница немного устарела (Джон:мы должны это исправить!).

Быть прозрачным; protobuf-net может подключиться к WCF через контракт;обратите внимание, что он прекрасно работает с MTOM и с базовым http.Однако это не работает с Silverlight, поскольку в Silverlight отсутствует точка внедрения.Если вы используете svcutil, вам также необходимо добавить атрибут в класс (через частичный класс).

Re BinaryFormatter (удаленное взаимодействие);да, это имеет полную поддержку;вы можете сделать это просто тривиальным ISerializable реализация (т.просто позвони в Serializer метод с теми же аргументами).Если вы используете protogen для создания ваших классов, он может сделать это за вас:вы можете включить это в командной строке через аргументы (по умолчанию это не включено, поскольку BinaryFormatter работает не на всех платформах [CF и т. д.]).

Обратите внимание, что для очень маленьких объектов (отдельные экземпляры и т. д.) при локальном удаленном взаимодействии (IPC) BinaryFormatter производительность на самом деле выше, но для нетривиальных графиков или удаленных ссылок (удаленное взаимодействие в сети) protobuf-net может значительно превзойти ее.

Я также должен отметить, что формат передачи буферов протокола не поддерживает наследование напрямую;protobuf-net может подделать это (сохраняя при этом проводную совместимость), но, как и в случае с XmlSerializer, вам необходимо заранее объявить подклассы.

---

Почему две версии?

Я думаю, это радость открытого исходного кода ;-p Мы с Джоном раньше работали над совместными проектами и обсуждали объединение этих двух проектов, но факт в том, что они нацелены на два разных сценария:

• dotnet-protobufs (Jon's) — это порт существующей версии Java.Это означает, что он имеет очень знакомый API для всех, кто уже использует версию Java, и он построен на типичных конструкциях Java (классы компоновщика, неизменяемые классы данных и т. д.) - с некоторыми изменениями C#.
• protobuf-net (Марка) представляет собой повторную реализацию того же двоичного формата (действительно, критическим требованием является возможность обмена данными между разными форматами), но с использованием типичных идиом .NET:
  • изменяемые классы данных (без конструкторов)
  • особенности члена сериализации выражаются в атрибутах (сравнимо с XmlSerializer, DataContractSerializer, и т. д)

Если вы работаете с клиентами Java и .NET, Jon's, вероятно, станет хорошим выбором для знакомого API с обеих сторон.Если вы используете чистый .NET, у protobuf-net есть преимущества — знакомый API в стиле .NET, а также:

• ты не принужденный быть сначала контрактом (хотя можно, и генератор кода поставляется)
• вы можете повторно использовать существующие объекты (фактически, [DataContract] и [XmlType] классы часто можно использовать вообще без каких-либо изменений)
• он имеет полную поддержку наследования (которого он достигает в сети путем подмены инкапсуляции) (возможно, уникально для реализации буферов протокола?обратите внимание, что подклассы должны быть объявлены заранее)
• он изо всех сил старается подключиться к основным инструментам .NET и использовать их (BinaryFormatter, XmlSerializer, ВКФ, DataContractSerializer) — позволяя ему работать напрямую как механизм удаленного взаимодействия.Вероятно, это будет довольно большое отличие от основного Java-транка для порта Джона.

Повторное объединение их;Я думаю, что мы оба были бы открыты для этого, но маловероятно, что вам понадобятся оба набора функций, поскольку они ориентированы на такие разные требования.