Чрезвычайно высокая скорость подкачки активной памяти на диск, но низкое использование постоянной памяти

Обновлено после получения дополнительной информации

Рабочий набор вашего приложения может быть не очень большим, но как насчет размера виртуальной памяти? Пейджинг может происходить из-за этого, а не только из-за его физического размера. См. этот снимок экрана из Process Explorer VS2012, работающего в Windows 8:

А в диспетчере задач? По-видимому, частный рабочий набор для того же процесса составляет 305 376 КБ.

Из этого мы можем сделать вывод: а) диспетчеру задач не всегда можно доверять и б) размер приложения в памяти, насколько это касается ОС, гораздо сложнее, чем нам хотелось бы думать.

Возможно, вы захотите взглянуть на это.

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

Затем удалите любую обработку (но сохраните загрузку изображения), которую вы делаете, и снова сравните - обратите внимание на разницу.

Затем полностью заглушите код загрузки изображения — обратите внимание на разницу.

Ясно, что вы увидите наибольшее падение ошибок, когда отключите загрузку изображения.

Теперь, глядя на Код изображения Emgu.CV, он использует класс Image внутри для получения битов изображения, так что это запускает GDI+ через функцию GdipLoadImageFromFile (вторая запись в этом указателе)), чтобы декодирует изображение (используя системные ресурсы, а также потенциально большие массивы байтов), а затем копирует данные в несжатый массив байтов, содержащий фактические значения RGB.

Этот байтовый массив выделяется с помощью GCHandle.Alloc (также окруженного GC.AddMemoryPressure и GC.RemoveMemoryPressure) для создания закрепленного байтового массива для хранения данных изображения (несжатых). Теперь я не специалист по управлению памятью .Net, но мне кажется, что у нас есть потенциал для фрагментации кучи здесь, даже если каждый файл загружается последовательно, а не параллельно.

Является ли это причиной жесткого пейджинга, я не знаю. Но это кажется вероятным.

В частности, представление изображения в памяти может быть специально ориентировано на отображение, а не на исходные байты файла. Так что если мы говорим, например, о JPEG, то JPEG размером 300 КБ может занимать значительно больше физической памяти, в зависимости от его размера. Например. 32-битное изображение 1027x768 занимает 3 МБ, и оно было выделено дважды для каждого изображения с момента его загрузки (первое выделение), а затем копирования (второе выделение) в объект изображения EMGU перед удалением.

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

Однако не всегда легко определить, какой процесс непосредственно отвечает за пейджинг и почему.

Дьявол кроется в этой отговорке. Растровые изображения отображаются в память из файла, содержащего данные пикселей, с помощью файла, отображаемого в памяти. Это эффективный способ избежать чтения и записи данных непосредственно в/из ОЗУ, вы платите только за то, что используете. Механизм, обеспечивающий синхронизацию файла с оперативной памятью, — это пейджинг. Поэтому неизбежно, что если вы обрабатываете много изображений, вы увидите много ошибок на странице. Инструмент, который вы используете, просто недостаточно умен, чтобы знать, что это сделано по замыслу.

Фича, а не баг.