Проблема производительности сериализации JSON в WP7 - PullRequest
5 голосов
/ 24 февраля 2011

У меня есть файл .JSON, который составляет ок. Размер 1,5 МБ, содержащий около 1500 JSON-объектов, которые я хочу преобразовать в доменные объекты при запуске моего приложения.

В настоящее время мой процесс на телефоне (не на моем компьютере для разработки) занимает около 23 секунд, что слишком медленно для меня и вынуждает меня записывать список объектов в ApplicationSettings, так что мне не нужно делать это каждый время загрузки приложения (только сначала), но даже это занимает 15 с лишним секунд для записи и 16 секунд для чтения, и все это на самом деле недостаточно хорошо.

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

В настоящее время я использую пространство имен System.Runtime.Serialization с подходами DataContract и DataMember.

Есть какие-нибудь идеи по производительности с этим типом загрузки данных?

Ответы [ 6 ]

4 голосов
/ 24 февраля 2011

Я обнаружил, что библиотека Json.NET более производительна и имеет лучшие параметры, чем стандартный сериализатор json.

Одна проблема с производительностью, с которой я столкнулся в своем приложении, заключалась в том, что мои доменные объекты реализовали INotifyPropertyChanged с кодом для поддержки отправки события обратно в поток пользовательского интерфейса. Так как код десериализации заполнил эти свойства, я делал много потоковых маршаллингов, которые не должны были присутствовать. Вырезание уведомлений во время десериализации существенно повысило производительность.

Обновление: Я использовал Caliburn Micro, у которого есть свойство на PropertyChangedBase, которое может отключать уведомления об изменениях свойств. Затем я добавил следующее:

[OnDeserializing]
public void OnDeserializing(StreamingContext context)
{
    IsNotifying = false;
}

[OnDeserialized]
public void OnDeserialized(StreamingContext context)
{
    IsNotifying = true;
}
1 голос
/ 25 февраля 2011

Здесь - пост о сериализации.Используйте двоичный файл или Json.Net.

1 голос
/ 25 февраля 2011

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

Меня все еще интересует необходимость в 1500 объектах. Вам действительно нужно 1500 всего объекта, и если да, то почему - в конечном счете, телефон что-то показывает пользователю, и ни один пользователь не может обрабатывать 1500 бит информации одновременно. Они могут обрабатывать только ту информацию, которая представлена, нет? Так есть ли возможные части объекта, которые вы можете показать, и ждать загрузки других частей позже? Например, если у меня 2000 контактов, я никогда не буду загружать 2000 контактов. Я мог бы загрузить 2000 имен, позволить пользователям фильтровать / сортировать имена, а затем, когда они выбирают имя, загружать контакт.

Я бы предложил сериализовать это в изолированное хранилище в виде файла. Встроенный сериализатор JSON занимает меньше всего места на диске и работает довольно хорошо.

1 голос
/ 24 февраля 2011

Попробуйте профилировать ваше приложение с помощью бесплатного EQATEC Profiler для WP7. Реальная проблема может быть чем-то совершенно неожиданным и легко решаемым, как упоминает пример INotifyPropertyChanged-примера Найджела.

0 голосов
/ 25 февраля 2011

Вы пытались использовать несколько меньших файлов и [де] сериализовать параллельно, чтобы увидеть, будет ли это быстрее?

0 голосов
/ 24 февраля 2011

Хранение / восстановление в ApplicationSettings также будет включать сериализацию (уверен, что это Xml), так что я не думаю, что вы когда-либо будете работать быстрее, чем 16 секунд, которые вы видите.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...