Использование памяти платформы объекта

Так как платформа объекта сохраняет данные в памяти (также, как и многие ORM's), затем как со многими наборами в оперативной памяти существуют, вероятно, внутренние массивы. Поскольку Вы добавляете объекты к набору, внутренний массив удваивается в способности.

Например, если Вы имеете набор как ArrayList, содержащий 256 объектов, и добавляете 257-й объект к нему, затем что происходит, внутренне новый блок памяти, выделяется для 512 массивов объекта, они, 256 массивов объекта копируются в новые 512 массивов объекта, и затем 256 массивов объекта сделаны доступными для сборки "мусора". Таким образом при переходе у Вас будет 768 объектов выделенными в памяти просто, потому что Вы добавили 257-й объект. Я столкнулся с головными болями с этим при использовании memorystream, потому что Вам нужно почти в 3 раза больше непрерывной нефрагментированной памяти, чем, в чем Вы действительно нуждаетесь. Это-.Capacity свойство, которое Вы видите на наборах, и это - почти всегда питание 2 (начиная с него дважды в размере по мере необходимости).

Моя ставка существуют внутренние массивы, которые удваиваются в размере по мере необходимости для поддержки наборов в объектах памяти. Таким образом, 300 000 объектов того же типа были бы, вероятно, сохранены во внутреннем массиве размера 524,288. Кроме того, если это похоже на подобные методы в другом месте в.NEt Framework, затем каждый раз, когда 262145-й объект был добавлен, и массив 262 144 и 524288 существовал в памяти, в то время как объекты были скопированы в новый массив. В общей сложности 786 432 объекта в памяти. Старый массив слонялся бы поблизости, пока сборщик "мусора" не решил, что больше не был необходим.

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

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

Ваши объекты могут быть «маленькими» с точки зрения фактических данных, но каждый объект не является DTO - Entity Framework прикрепляет много шаблонного кода к каждой из ваших сущностей, что означает, что фактический размер каждого объекта довольно велик.

Если вы постоянно работаете с большими графами объектов, рассмотрите возможность использования чего-то вроде NHibernate, который стабилен, зрел и доказал свою работоспособность. Entity Framework очень сильно отстает в плане возможностей и производительности.