protobuf потребляет большую часть выделенной памяти в задаче wp8 scheduleagent

Я создаю WP8 с запущенной фоновой задачей (ScheduledAgent). Когда задача выполняется, она загружает из изолированного хранилища граф объектов, сериализованный с помощью protobuf. Модель классов состоит из примерно 10 классов с головным объектом User, у которого есть списки других экземпляров класса. Модель не тривиальная, но и не слишком сложная.

Моя проблема в том, что к моменту восстановления графика большая часть выделенной мне памяти израсходована (примерно 1 МБ для запланированной задачи). Я сузил основной виновник как сам протобуф. Я предполагаю, что метаинформация времени выполнения о модели класса потребляет большую часть памяти, но вызов FlushPool, похоже, вообще не помогает.

Восстановление пустых графов объектов требует примерно столько же памяти, сколько и полностью загруженный объект. Я ищу любой возможный способ очистить все ссылки на память, хранящиеся внутри protobuf, а затем вызываю GC.Collect, надеясь восстановить достаточно, чтобы выполнить фактическую работу. Есть ли что-то другое, чем FlushPool ()?

Спасибо


person user3025020    schedule 23.11.2013    source источник
comment
Я предполагаю, что это protobuf-net, да? Вопрос: используете ли вы полную сборку или CoreOnly с инструментом предварительной компиляции?   -  person Marc Gravell    schedule 23.11.2013
comment
protobuf-net. Я использую полную сборку.   -  person user3025020    schedule 24.11.2013
comment
Если вы подозреваете, что много информации находится на мета-уровне, переключение на CoreOnly через предварительную компиляцию полностью удалит все это - плюс ускорит работу. Стоит попробовать? marcgravell.blogspot.com/2012/07/   -  person Marc Gravell    schedule 24.11.2013
comment
ЭТО СДЕЛАЛО !!!! СПАСИБО. Интересно, что я попытался использовать netwonsoft / json.net для решения проблемы, и у него был такой же объем памяти. Мне интересно, не связана ли реальная проблема с библиотеками отражения wp8.   -  person user3025020    schedule 24.11.2013
comment
Меня это не удивит.   -  person Marc Gravell    schedule 24.11.2013


Ответы (1)


Любые дополнительные накладные расходы могут возникнуть из-за аспектов отражения и метапрограммирования «полной» сборки. Хорошая новость заключается в том, что если это так: вы можете удалить все это, используя прекомпилятор, чтобы переместить все метапрограммирование на этап сборки. Чтобы убедиться, что вы не включаете какой-либо метапрограммный код, вы можете использовать сборку CoreOnly со сгенерированной сборкой сериализации.

person Marc Gravell    schedule 24.11.2013