Мне тоже так казалось в соответствии со статистическими знаниями.. но не тут то было! Покапавшись в инете вот что вскрылось:
"В многозадачной системе Windows, никакая программа не владеет всеми ресурсами системы единолично и вынуждена делить их с остальными задачами. А это значит, что скорость выполнения профилируемой программы не постоянна и находится в тесной зависимости от "окружающей среды". На практике разброс результатов измерений может достигать 10%—15%, а то и больше, особенно, если параллельно с профилировкой исполняются интенсивно нагружающие систему задачи.

Тем не менее, особой проблемы в этом нет, — достаточно лишь в каждом сеансе профилировки делать несколько контрольных прогонов и затем… нет, не усреднять, а выбирать замер с наименьшим временем выполнения. Дело в том, что измерения производительности — это не совсем обычные инструментальные измерения и типовые правила метрологии здесь неуместны. Процессор никогда не ошибается и каждый полученный результат точен. Другое дело, что он в той или иной степени искажен побочными эффектами, но! Никакие побочные эффекты никогда не приводят к тому, что программа начинает исполняться быстрее, нежели она исполняется в действительности, а потому, прогон с минимальным временем исполнения и представляет собой измерение в минимальной степени испорченное побочными эффектами.

Кстати, во многих руководствах утверждается, что перед профилировкой целесообразно выходить из сети ("что бы машина не принимала пакеты"), завершать все-все приложения, кроме самого профилировщика и вообще лучше даже "на всякий случай" перегрузиться. Все это чистейшей воды бред! Автор частенько отлаживал программы параллельно с работой в Word, приемом корреспонденции, загрузкой нескольких файлов из Интернета и при этом точность профилировки всегда оставалась удовлетворительной! Конечно, без особой нужды не стоит так рисковать, и параллельно работающие приложения перед началом профилировки, действительно, лучше завершить, но не следует доводить ситуацию до абсурда, и пытаться обеспечить полную "стерильность" своей машине. "

Сообщение отредактировал beaRTS - Dec 20 2012, 07:13

> прогон с минимальным временем исполнения и представляет собой измерение в минимальной степени испорченное побочными

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

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

Напротив, при профилировании функций, исполняющихся в реальной программе всего один раз, следует обращать внимание лишь на время первого прогона и отбрасывать все остальные"

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

Ндаа. =) как это все неоднозначно.
Спасибо! подчерпнул для себя что-то новое. Но пока не готов трудо-дни тратить на углубление в профилировании.

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

Сообщение отредактировал beaRTS - Dec 20 2012, 08:05

Пример трассировки на РС одной вычислительной функции в ticks
Нормальный приоритет:
N: 100
Tmax: 47267
Tmin: 22509
Tmean: 27899
Tstd: 3913

RealTime приоритет:
N: 100
Tmax: 31293
Tmin: 22754
Tmean: 27241
Tstd: 1700

наверно, так и стоит делать, собирая всю статистику целиком. я Вас понял, применю при случае. спс