Стратегии работы с большими объемами данных изображений

Стек технологий: C # / .NET 4 / WinForms

Предпосылки:

Проект, над которым я работаю, представляет собой приложение визуализации для серии стеков изображений. В частности, каждый стек изображений выравнивается по сетке, показывает одно и то же изображение в любой момент, а функции обработки применяются к изображениям, просматриваемым в данный момент.Сами стеки изображений составляют 150–300 МБ, а каждое изображение - от 512 КБ до 1 МБ.Типичный набор данных будет состоять из ~ 100 стопок изображений.

Вопрос:

Чтобы попробовать работать с таким объемом данных, я использую несколько технических средств:

• файлы с отображением памяти: стеки изображений загружаются с диска при запуске приложения
• компиляция под x64 с небезопасным кодом. : Очевидно, мне нужно 64-битное адресное пространство для файлов такого размера. Я перемещаю отображаемое в данный момент изображение из файла с отображением памяти в метод, который генерирует растровое изображение с помощью Marshal.Copy с небезопасными указателями.
• System.Threading.Tasks: я использую параллельные циклы для обработки, где это возможно
• System.Drawing.BufferedGraphicsContext: каждый стек изображений имеет одно активное изображение, которое объединяется в BufferedGraphicsContext перед передачей в PictureBox для отображения в Пользователь.
• Высококачественные системные требования: четырехъядерный процессор или лучше, SSD, 12 ГБ памяти и т. Д.

Однако даже при использовании всего вышеперечисленного скорость отклика оставляет желать лучшего. При использовании SysInternals Process Explorer загрузка ЦП низкая (<25%), в то время как использование памяти достигает предела до того, как произойдет сборка мусора.

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

Что еще я могу сделать для повышения производительности?

Примечание:

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

Обновление 1:

• Что касается памяти, то в моем блоке разработки только 6 ГБ (в результате я пытаюсь загрузить меньше файлов), но в системе развертывания будет 24 ГБ.
• Я собираюсь использовать оптимизацию SSE с помощью примитивов производительности Intel и ускорение графического процессора с помощью CUDA.
• Причина, по которой я пытаюсь загрузить все данные в память, заключается в том, что важным этапом визуализации является циклическое переключение стеков изображений с частотой 15–60 Гц, и я боялся, что меня перебьют.