XML по сравнению с Двоичной производительностью для Сериализации/Десериализации

Интересно ... мысли:

• какая это версия CF; 2.0? 3,5? В частности, в CF 3.5 есть Delegate.CreateDelegate , который позволяет protobuf-net получать доступ к свойствам намного быстрее, чем в can в CF 2.0
• , аннотируете ли вы поля или свойства ? Опять же, в CF оптимизация отражения ограничена; вы можете получить лучшую производительность в CF 3.5 с помощью свойств , так как с полем единственный доступный вариант - FieldInfo.SetValue

Есть ряд других вещей, которых просто не существует в CF, поэтому он должен идти на компромиссы в нескольких местах. Для слишком сложных моделей существует также известная проблема , связанная с общими ограничениями CF . Исправление в процессе, но это большое изменение, и оно займет «некоторое время».

Вы пробовали создавать собственные классы сериализации для своих классов? Вместо использования XmlSerializer, который является сериализатором общего назначения (он создает кучу классов во время выполнения). Для этого есть инструмент (sgen). Вы запускаете его в процессе сборки, и он создает настраиваемую сборку, которую можно использовать вместе с XmlSerializer.

Если у вас Visual Studio, этот параметр доступен на вкладке «Сборка» в свойствах вашего проекта.

Инструмент sa для этого (sgen). Вы запускаете его в процессе сборки, и он создает настраиваемую сборку, которую можно использовать вместе с XmlSerializer.

Если у вас Visual Studio, этот параметр доступен на вкладке «Сборка» в свойствах вашего проекта.

Инструмент sa для этого (sgen). Вы запускаете его в процессе сборки, и он создает настраиваемую сборку, которую можно использовать вместе с XmlSerializer.

Если у вас Visual Studio, этот параметр доступен на вкладке «Сборка» в свойствах вашего проекта.

Я собираюсь исправить себя в этом, - указал Марк Гравалл, первая итерация связана с накладными расходами на построение модели, поэтому я провел несколько тестов, взяв в среднем 1000 итераций сериализации и десериализации как для XML, так и для двоичного кода. Я попробовал свои тесты сначала с v2 библиотеки Compact Framework DLL, а затем с v3.5 DLL. Вот что у меня получилось, время в мс:

.NET 2.0
================================ XML ====== Binary ===
Serialization 1st Iteration      3236       5508
Deserialization 1st Iteration    1501       318
Serialization Average            9.826      5.525
Deserialization Average          5.525      0.771

.NET 3.5
================================ XML ====== Binary ===
Serialization 1st Iteration      3307       5598
Deserialization 1st Iteration    1386       200
Serialization Average            10.923     5.605
Deserialization Average          5.605      0.279

Снижается ли производительность при сериализации объектов или их записи в базу данных? Поскольку их написание, вероятно, приведет к некоторому замедлению работы хранилища, я полагаю, что это будет гораздо большим ударом по производительности, чем этап сериализации.

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

В какой базе данных вы их храните? Сериализуются ли объекты в памяти или сразу в хранилище? Как их отправляют в БД? Насколько велики объекты? При обновлении одного объекта вы отправляете в базу данных все объекты или только тот, который был изменен? Вы вообще что-нибудь кэшируете в памяти или каждый раз перечитываете из хранилища?

XML часто обрабатывается медленно и занимает много места. Было предпринято несколько различных попыток решить эту проблему, и наиболее популярной на сегодняшний день, похоже, является просто опускание партии в файл gzip, как в случае Open Packaging Convention .

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