Изменение объёма памяти при OutOfMemoryException

Приветствую всех.
Проблема такова: я сделал add-in для MS Word, который в некоторых случаях очень требователен к памяти. Соответственно, часто возникает OutOfMemoryException. Я пытаюсь с ним бороться частой принудительной сборкой мусора (GC.Collect), но не очень преуспел. Также логирую объём свободной оперативки - и отмечаю, что она есть в наличии даже при возникновении OutOfMemoryException. Так что мне кажется, что проблемы скорее в том, что просто превышается максимальный размер памяти, допустимый для процесса.
Начал копать в эту сторону. Наткнулся на кучу свойств у Process: WorkingSet64, PeakWorkingSet64, MaxWorkingSet и иже с ними. И что-то не могу в них разобраться.
Итак, как я понял из описания, WorkingSet64 должен возвращать текущий объём памяти в байтах, а MaxWorkingSet - задавать максимальный допустимый объём памяти (причём MaxWorkingSet имеет тип IntPtr...). Ну ладно, я создал тестовое приложение и смотрю на значения этих свойств для Process.GetCurrentProcess() (возвращённые значения делю на 1024, приводя к килобайтам):

• WorkingSet64 возвращает 67 148 КБ
• PeakWorkingSet64 возвращает 73 532 КБ (ну да, логично, это максимальный объём, когда-либо использовавшийся процессом)
• а вот MaxWorkingSet возвращает 1 380 КБ!
• при этом в диспетчере задач для процесса указан объём 35 656 КБ!

Видимо, я чего-то не понимаю. Почему MaxWorkingSet в несколько раз меньше текущего объёма памяти? Почему не совпадает значение в диспетчере задач и в WorkingSet64 ?
И если будут иные советы по разрешению ситуации, буду благодарен.
Если это важно, пишу под Framework 4.0 (чтобы была поддержка WinXP), ОС сейчас Windows 7 и 64-х битная машина, хотя OutOfMemory возникает в-основном на 32-битных компьютерах с Windows XP.

0

вычищай свой говнокод и всё пройдет, гугли что такое IDisposable, зачем нужны Close и т.п
а эти глупости забудь смело, как и о существовании GC.Collect

Добавлено через 50 секунд
алгоритмы распределения памяти в ОС умней большинства программистов сталкивающихся с OutOfMemory

2

m0nax, Вы ещё про using и finally расскажите.
Хотя будет интересно услышать предложение, что мне сделать IDisposable, если в коде используются только списки, массивы, словари и COM-объекты Ворда. Может, дотнетовские библиотеки переписать?

0

Сообщение от pokibor что мне сделать IDisposable,

Сообщение от pokibor COM-объекты Ворда

COM объекты уничтожаются с помощью ReleaseComObject.
Такая же ситуация с Excel - нужно каждый объект релизить, и желательно(а мб и необходимо) в правильной последовательности.
http://stackoverflow.com/quest... op-objects

Сообщение от pokibor только списки, массивы, словари

Обнуляйте ссылки - GC сам справится.

1

Woldemar89, спасибо!
Насчёт ReleaseComObject идея правильная, хотя не уверен, что это освободит сильно много памяти (всё же основную часть списки и массивы жрут). Что касается обнуления ссылок, то я всегда стараюсь вызвать .Clear для словарей и списков после использования, если Вы имели это в виду. Насчёт = null для массива посмотрю, но массивы вроде только в самом конце процесса используются.

Всё же хочется узнать, как лучше увеличить объём доступной памяти (дело в том, что чем больше её доступно - тем с более здоровыми документами можно работать).
Насколько я разобрался, MaxWorkingSet вызывать без толку, как и функции WinAPI - это только рекомендации. Поскольку Word - 32-х битный, то и add-in вызывается в 32-х битной среде и значит, ограничен 2 Гб адресного пространства. Немного не ясно, почему же тогда столько процесс в памяти не занимает, но скорее всего, тут используется какая-то виртуализация.
Понятно, что лучший способ - вынести часть кода в другой процесс. Но нельзя ли решить задачу как-то проще - через вызова кода в другом AppDomain, например?

0

pokibor, мне кажется, вы не туда копаете, подход неправильный.
Приведите пример, объясните как идет обработка. Что на входе, что на выходе.

Для справки:
docx и xlsx - переименуйте в zip. Откройте, и структуру посмотрите. Это обычные zip архивы.
Возможно, можно просто распаковать, да работать с xml? Или типа того...

Короче мне лень дальше ванговать - рассказывайте процесс подробно от и до на небольшом примере.

1

Сообщение от pokibor всё же основную часть списки и массивы жрут

Звучит так, как будто вы выполнили профилирование и уже точно знаете, что и где у вас память жрёт. В таком случае непонятно, что тут обсуждается...

Я это к чему. Очень многое зависит от вашего кода и, как заметил Woldemar89, не зная что и как он делает, гадать о причинах можно долго. Но хочу заметить, что COM-объекты ворда очень толстозадые (как-никак работают с DOM документов). Поэтому старайтесь релизить эти объекты как можно раньше.

И IDisposable - это вам намёк на то, что время жизни многих объектов вашей программы можно (и нужно, раз такое дело) принудительно ограничить, что снизит затраты памяти...

1