Фрагментация памяти WPF

Question

У меня есть то, что я предполагаю, это проблема фрагментации памяти.

Мы недавно перенесли наше приложение WinForms в приложение WPF. Есть некоторая обработка изображений, что это приложение делает, и эта обработка всегда работала в версии WinForms приложения. Мы переходим в WPF, и обработка умирает. Отладка в библиотеке имеет смерть в случайных точках, но всегда с массивом, который является нулевым, т. Е. Сбой распределения.

Сама обработка выполняется в библиотеке C++, вызванной p/invoke и достаточно интенсивной в памяти; если заданное изображение равно N x M пикселей, тогда изображение равно N x M x 2 байта (каждый пиксель без знака, и это изображение в оттенках серого). Во время обработки создаются пирамиды изображений, которые находятся в пространстве с плавающей точкой, поэтому общее использование памяти будет равно N x M x (2 + 2 + 4 + 4 + 4 + 4), где первые 2 являются входными, вторая 2 - выход, первый 4 - вход в поплавках, второй 4 - изображение разности уровней 0-го уровня, а последние две четверти - остальная часть пирамиды (поскольку они являются пирамидами, а каждый уровень равен половине размера в каждом направление, эти 4s являются верхними границами). Таким образом, для изображения 5000х6000 это 600 мб, которое должно вписываться в память просто отлично.

(Существует вероятность того, что использование маршаллинга увеличивает потребность в памяти другим N x M x 4, то есть входные и выходные изображения на стороне C#, а затем те же массивы, скопированные на сторону C++, - может быть, маршаллинг требование больше?)

Насколько фрагментирован WPF по сравнению с WinForms? Есть ли способ консолидировать память перед запуском этой обработки? Я подозреваю, что фрагментация является проблемой из-за случайного характера разломов, когда они происходят, и что это всегда проблема распределения памяти.

Или я должен полностью избегать этой проблемы, выполнив обработку как отдельный процесс, с передачей данных через сокеты или с подобной подобной вещью?

Answer 1

Если я прочитал это правильно, сбой памяти не происходит, а не с управляемой стороны. Кажется странным тогда обвинять WPF. Я понимаю, что вы делаете свое заключение на основании того, что «он работал в WinForms», но, скорее всего, больше изменений, чем просто это. Вы можете использовать такой инструмент, как .NET Memory Profiler, чтобы увидеть различия между тем, как приложение WPF и приложение WinForms обрабатывают память. Вы можете обнаружить, что ваше приложение делает то, чего вы не ожидаете. :)

За комментарий: Да, я понимаю. Если вы уверены, что вы исключили такие вещи, как изменения в окружающей среде, я думаю, вам нужно взять копию BoundsChecker и Memory Profiler (или DevPartner Studio) и вникнуть и посмотреть, что мешает вашему распределению памяти.

Answer 2

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

Редактировать: Из любопытства вы также можете предварительно выделить всю свою память спереди (я не вижу код, поэтому не знаю, возможно ли это), и убедитесь, что все ваши указатели non-null, так что вы можете проверить, что это происходит в распределении памяти, а не какая-то другая проблема?

Answer 3

Похоже, вы хотите быть более внимательными к управлению памятью в целом; т.е.: либо запустите движок обработки в отдельном адресном пространстве, которое тщательно управляет памятью, либо предварительно распределите достаточно большой фрагмент, прежде чем память будет слишком фрагментирована и будет управлять изображениями только в этой области. Если вы используете адресное пространство с помощью.NET в длительном процессе, и вам нужны большие смежные области, в какой-то момент это всегда будет потенциально терпеть неудачу. Просто мой 2c.

Answer 4

Это сообщение может быть полезным http://blogs.msdn.com/tess/archive/2009/02/03/net-memory-leak-to-dispose-or-not-to-dispose-that-s-the-1-gb-question.aspx