C # Непонятные результаты теста производительности - PullRequest
Новая
       12

C # Непонятные результаты теста производительности

2 голосов
/ 29 марта 2010

В настоящее время я работаю над приложением для обработки изображений. Приложение захватывает изображения с веб-камеры и затем обрабатывает их. Приложение должно реагировать в режиме реального времени (в идеале <50 мс для обработки каждого запроса). Я проводил некоторые временные тесты в своем коде и нашел что-то очень интересное (см. Ниже). </p> 

clearLog();
log("Log cleared");

camera.QueryFrame();
camera.QueryFrame();
log("Camera buffer cleared");

Sensor s = t.val;
log("Sx: " + S.X + " Sy: " + S.Y);

Image<Bgr, Byte> cameraImage = camera.QueryFrame();
log("Camera output acuired for processing");

Каждый раз, когда вызывается log, отображается время с начала обработки. Вот мой вывод журнала: 

[3 ms]Log cleared
[41 ms]Camera buffer cleared
[41 ms]Sx: 589 Sy: 414
[112 ms]Camera output acuired for processing

Время вычисляется с использованием StopWatch из System.Diagonostics. Время, указанное выше, составляет кумулятивно . Таким образом, Log Clear занял 3 мс. И "Camera буфер очищен" взял (41-3 = 38мс).

ВОПРОС 1

Я нахожу это немного интересным, поскольку, когда один и тот же метод вызывается дважды, он выполняется за ~ 40 мс, а когда он вызывается один раз в следующий раз, это занимает больше времени (~ 70 мс).

Назначение значения не может занимать так много времени, верно?

ВОПРОС 2

Также время для каждого шага, записанного выше, время от времени меняется. Значения для некоторых шагов иногда составляют всего 0 мс, а иногда и 100 мс. Хотя большая часть чисел выглядит относительно последовательной.

Я полагаю, это может быть из-за того, что процессор использовался каким-то другим процессом в это время? (Если это по какой-то другой причине, пожалуйста, дайте мне знать)

Есть ли способ гарантировать, что при запуске этой функции она получает наивысший приоритет? Так что результаты теста скорости будут постоянно низкими (с точки зрения времени).

EDIT

Я изменил код, чтобы удалить два пустых фрейма запроса сверху, поэтому код теперь: 

clearLog();
log("Log cleared");

Sensor s = t.val;
log("Sx: " + S.X + " Sy: " + S.Y);

Image<Bgr, Byte> cameraImage = camera.QueryFrame();
log("Camera output acuired for processing");

Результаты синхронизации теперь: 

[2 ms]Log cleared
[3 ms]Sx: 589 Sy: 414
[5 ms]Camera output acuired for processing

Следующие шаги теперь занимают больше времени (иногда следующий шаг переходит через 20-30 мс, в то время как следующий шаг ранее был почти мгновенным). Я предполагаю, что это связано с планированием процессора. Могу ли я каким-то образом убедиться, что ЦП не запланирован на выполнение других действий во время работы с этим кодом?

Ответы [ 2 ]

1 голос
/ 01 апреля 2010

Может случиться так, что камера на самом деле не «захватывает кадр», когда вы просите об этом, но делает это все время. Затем, когда вы запрашиваете данные изображения, и они достаточно свежие, данные сразу возвращаются. Но если вам не повезло, а данные устарели, тогда вам придется ждать получения нового изображения. Если камера делает 25 кадров в секунду, это может означать задержку в 50 мс (не только фактический сбор фотонов, но и передача данных).

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

0 голосов
/ 29 марта 2010

Без источника почти невозможно сказать «что возможно».

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

Вы пробовали использовать профилировщик? Это может ответить на ваш вопрос относительно того, что еще делает процесс в то время.

...