Минимизировать объем памяти ADO.NET DataSet?

Question

Учитывая унаследованную систему, которая интенсивно использует наборы данных и практически не имеет возможности заменить их бизнес-объектами или другими, более эффективными структурами данных:

Существуют ли какие-либо методы для уменьшения объема памяти в DataSet?

Я думаю о таких вещах, как установка начальной емкости (если она известна), снятие ограничений и т. Д., Но у меня мало опыта с наборами данных, и я не знаю, какие конкретные параметры могут быть доступны для меня или какие-то из них будут иметь значение все.

Обновление:

Мне известны возможности долгосрочного рефакторинга, но я ищу быстрые исправления с учетом набора объектов DataTable, хранящихся в DataSet, то есть, какие свойства, как известно, влияют на накладные расходы памяти.

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

Answer 1

Это, к несчастью, помочь вам, но может сильно помочь в тех же случаях.

Если вы храните много одинаковых строк в наборе данных, например, названия городов, посмотрите только на использование одного строкового объекта с каждой отдельной строкой.

, например

Directory <string, string> towns = new Directory <string, string>();
foreach(var row in datatable)
{
    if (towns.contains(row.town))
    {
       row.town = towns[row.town]
    }
    else
    {
       towns[row.town] = row.town;
    }
}

Тогда GC может восстановить большинство дублированных строк, однако это работает только в том случае, если наборы данных живут в течение длительного времени.

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

Answer 2

Вы можете попытаться заставить ваши таблицы и строки реализовывать интерфейсы в коде позади файлов. Затем со временем измените код, чтобы использовать эти интерфейсы, а не непосредственно таблицу / строки.

Как только большая часть вашего кода просто использует интерфейсы, вы можете использовать сгенерированный код для создания класса C #, который реализует эти интерфейсы без затрат на строки / таблицы.

Однако может быть дешевле перейти на 64-битную версию и купить больше оперативной памяти ...

Answer 3

1. Если вы используете VS2005 +, вы можете создавать экземпляры объектов DataTable, а не весь DataSet. В 2003 году, если создается экземпляр DataTable, он поставляется с DataSet по умолчанию. 2005 и позже, вы получите только DataTable.

2. Посмотрите на свой уровень доступа к данным для заполнения DataSets или DataTables. Чаще всего бывает слишком много данных. Сделайте ваши запросы более конкретными.

3. Убедитесь, что код, который вы используете, не делает глупостей, таких как копирование DataSets, когда они передаются. Убедитесь, что вы используете .Select инструкции или DataViews для фильтрации и сортировки, а не делать копии.

Для DataSets не так много быстрых "оптимизаций". Если у вас проблемы с памятью, используйте пункты 2 и 3. Это будет иметь место независимо от того, какой тип объекта передачи данных вы будете использовать.

И хорошо разбираться в DataSets. Если вы не знакомы с ними, вы можете делать глупости, например, с чем угодно. Затем вы напишите статьи о том, как они отстой, а на самом деле статьи о том, как мало вы о них знаете Они действительно довольно полезны и просты в обслуживании. Пара советов:

• Использовать типизированные наборы данных. Они сэкономят вам массу кода и будут напечатаны, что поможет с простой проверкой.
• Если вы используете типизированные DS, убедитесь, что вы не изменяете сгенерированный файл кода. Если вы используете VS2005 +, вы можете поместить любое пользовательское поведение бизнес-объекта в частичный класс для DS (не в файл кода .designer).
• Используйте DataView и .Select, где бы вы ни находились, просматривая объекты DataRow.
• Найдите хороший инструмент для генерации кода и создайте рациональную структуру доступа к данным для заполнения и обновления из DS. Одна из проблем заключается в том, что иногда дизайнеры связывают дизайн DS непосредственно с таблицами в БД, что делает проект хрупким к изменениям структуры данных. Если вы должны это сделать, создайте или используйте генератор кода для создания уровня доступа к данным из БД, например CodeSmith. Начнем с рассмотрения некоторых шаблонов CodeSmith для создания хранимых процедур и классов доступа к данным.
• Помните, что при разговоре с кем-то об «объектах» и «наборах данных» в данном случае объектом является DataRow, а не DataSet. А благодаря частичным классам вы можете поместить поведение в «объект», что дает вам 95% преимуществ «объектов» для тех, кто любит писать код.