C # фоновый поток вызывает задержку в пользовательском интерфейсе

Question

Я работаю над системой обработки изображений в реальном времени.

Поток пользовательского интерфейса: захватывает изображения с камеры со скоростью 14 кадров в секунду через таймер и выполняет некоторую обработку / отображение. Каждые 2 секунды 3 изображения (около 1 МБ на диске каждый) выбираются путем обработки для записи на диск. Они помещаются в общую очередь.

Второй поток: удаляет изображения и записывает на диск. Был дан самый низкий приоритет.

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

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

Answer 1

в реальном времени, Windows и C # не ладят друг с другом. если это «неприемлемо» для частоты кадров когда-либо опускаться ниже 14fps, вы можете найти какое-то расширение для окон в реальном времени, например RTX или INtime .

Вы также можете попытаться записать файлы на диск меньшими порциями, добавить короткий Thread.Sleeps () между операциями записи, чтобы разрешить больше переключений задач и обеспечить очистку файлового потока после каждой записи.

Answer 2

Чтобы получить серьезный ответ, вы должны использовать какой-то инструмент профилировщика. Если вы ищете в стеке поток или Google, вы найдете их много. В основном вам приходится платить за них, но, к счастью, существуют также пробные версии, которые вы можете проверить, чтобы найти проблему.

Но мое дикое предположение без какого-либо профилировщика состоит в том, что операция ввода-вывода на диске приводит к проблемам с производительностью. Так что, возможно, вы можете работать против этого, если вы попытаетесь использовать SparseFile и / или MemoryMappedFile s (я знаю, что это .Net 4, но потому что это просто оболочка против Win32 Api, вы можете извлечь класс оттуда и использовать его в .Net 2).

Answer 3

Как и другие говорили: тяжелое реальное время здесь не сработает.

Попытайтесь выяснить, имеют ли устройства общие ресурсы (плохой пример: находятся ли на одной шине USB и диск, и камера). Проверьте с помощью профилировщика, является ли центральный процессор, который регулирует ваш захват или IO. Возможно, это просто ошибка вашего кода (утечка ресурсов, потеря времени). Никто не может сказать, но вы можете (и должны) проверить это.

Возможное «решение», в зависимости от ваших выводов:

Используйте очередь (например, msmq) и просто накапливайте изображения и никогда не читайте оттуда (даже с уменьшенным приоритетом потока), пока не достигнете своей "паузы". Это действительно потребовало бы «достаточного количества ОЗУ».

Answer 4

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