то ли у меня что-то  со зрением, то ли в первом посте такого вопроса нет. в первом посте есть вопрос "вот код, вызывающий Testee f N раз и засекающий время с помощью секундомера".
Что там в f() - сложение 2+2, вызов модуля, дергающего пару распределенных транзакций, триггер для запуска космической ракеты - хз. 

Что именно ты хотел спросить? Как более точно поменять время работы функции? Как правильнее использовать класс Stopwatch? Как правильнее подойти к оценке производительности в целом?

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

Если коротко, то:
Фраза

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

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

Для тех у кого проблемы со зрением:
   ЗАДАЧА: получить коллбэк, замерить среднее время его работы.

Если вам не понятна задача, или не знаете как решить эту задачу лучше, чем код в 1м посте - просто не пишите в этой теме.

1) мы с вами, уважаемый Abyx, на "ты" не пили.
2) было

стало

Для тех кто не знает значения некоторых слов русского языка (словарь Ожегова):

Время - (домашнее задание: найти в словаре значение слова) - это не мера объема выполняемой работы в единицу времени.

А теперь очень сложная задача для особенных людей: найти 8 отличий значения слова "произвоидительность" от "время".

Ну эт все лирика...

Флудер, это вы к чему?
Модератор: к бану

Это сообщение отредактировал(а) PashaPash - 24.6.2010, 09:57

Этот код не содержит описания задачи. Этот код замеряет время N вызовов функции. Больше он ничего не содержит.


Далее написано что надо сделать точнее или правильнее. Точнее или правильнее, чем взять функцию и замерять время на N вызовов.




Для совсем тугих и слепых - ты сам попросил более точный способ чем  "получить коллбэк, замерить среднее время (или число тактов) его работы.". Способ привели и обосновали. Тугота или слепота мешает его понять?

jonie, PashaPash, 
вы можете ответить на вопрос в посте http://forum.vingrad.ru/index.php?showtopi...t&p=2174118 ?

Abyx, выше уже ответил - твой код вполне решает эту задачу. Разве что ticksCounter.ElapsedTicks на nRuns поделить осталось. Ну и секундомер внутри цикла можно не трогать.
Точнее - никак. В твоем варианте точность измерения на пару порядков превышает ошибку из-за неучтенных внешних факторов (которые появяться во время внеднения функции в приложение)
Правильнее, без смены подхода - тоже никак.

PashaPash, если вы не знаете как лучше, зачем вообще писали в этой теме?

(на nRuns давно уже поделил)
(секундомер внутри цикла трогается чтобы был UI, тест может длиться минуты, юзер должен знать что прога не сдохла)

Опять 25... Тебе уже раз 5 объяснили как лучше (==правильнее). Если совсем не доходит, краткое содержание предыдущих мессаг:
Abyx: фотка проселочной дороги и руки с вытянутой линейкой. подпись: как лучше/точнее?
PashaPash, jonie:  проедь на машине и посмотри километраж. ну в крайнем случае на велосипеде и посчитай обороты колеса. все равно на кочках точность теряется.
Abyx: вам что, непоянтно? я же меряю проселочную дорогу миллиметровой линейкой! а вы предлагаете не ту задачу решать. как лучше/точнее?
PashaPash, jonie:  проедь на машине и посмотри километраж. ну в крайнем случае на велосипеде и посчитай обороты колеса. все равно на кочках точность теряется.
Abyx: вы, тупые флудеры, не умеете пользоваться линейкой - молчите.

повторить 3 раза...


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

Если уж очень хочется микротестировать, вот пару статей на тему:
http://msdn.microsoft.com/en-us/magazine/cc500596.aspx
http://msdn.microsoft.com/en-us/magazine/cc507639.aspx
Блог автора: http://blogs.msdn.com/b/vancem/

Я заметил, что часто люди не разбирающиеся в вопросе, все равно начинают что-то отвечать. Естественно они пишут то что знают. 
Плохо то что при этом они еще начинают наезжать на ТСа, говоря что мол он задает неправильные вопросы.


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

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

В случае если функция, скорость которой измеряется, выполняется быстро точность измерений можно повысить, изменив приоритет процесса и потока, и делая принудительное переключение потоков до и после каждого измерения. Также можно избавиться от влияния вызовов Start\Stop, вычитая время их выполнения.
В случае если функция, скорость которой измеряется, выполняется долго - код можно сделать intrusive, заставив функцию вызывать start\stop самой, или заставив ее выполнять rdtsc и возвращать количество тактов. Впрочем, если код должен быть non-intrusive, тут наверное действительно ничего не сделать.

Собственно два абзаца выше - это минимальный ответ на вопрос заданный в этой теме.

Abyx, Счет на такты, тысячепроцентные погрешности при выводе - о каких мелочах ты думаешь....ничего не упускаешь... кроме пары моментов:
- в любой момент (точнее, не совсем в любой, а при выделении твоим алгоритмом памяти под объект) сборщик мусора может тупо остановить твой сверхбыстрый алгоритм, и дать погрешность в сотню миллионов тактов. Алгоритм сборки мусора (размер поколений, например) самонастраивающийся, и в живой системе параметры будут совсем не такие, как при тестировании. про это писали выше, кстати. 
- при первом вызове метода происходит его компиляция из IL в native code. Тоже откушивая пару миллионов тактов.
- в любой момент JIT компилятор, теоретически, может решить что пора его перекомпилировать в целях оптимизации. откушав еще десяток миллионов тактов.


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

В целом, очень забавно наблюдать за еще одной попыткой микротестирования... из них всегда делаю далекоидущие выводы, например, тут в соседнем топике пару страниц спорили, что быстрее, for или foreach.  

Добавлено @ 00:39

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

Это сообщение отредактировал(а) PashaPash - 29.6.2010, 00:39

  
Abyx, извините, а вы еще сотрудник конторы в которой вы были до старта этого  топика? Если да, то покажите начальнику ссылку на это...

в общем так: чтобы точнее замерить надо написать драйвер PCI шины, поднять до максимума его ioctl и замерять время в нем... далее надо еще поднарпячься выгрузив другие драйвера ненужные вроде usb-шных (а-то малоли замеры времени будут неточные). Посколько мне кажется что C# хреново оптимизирует, но хочется .net то весь код надо переписать на IL руками (с ручной оптимизацией). Далее: надо пройтись ngen-ом. Потом: дописать систему загрузки сборок из кеша (выставлять потоку критичный приоритет при старте). Вот теперь МОЖНО мерять - остальное настоящие пацаны не считают замерами времени. Драйвер и только драйвер как я описал выше !

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


отлично, значит 1й вызов надо отбрасывать.

настройки сборщика мусора (==частота сборки) зависят от работы приложения до вызова функции, от количества процессоров, от установленных патчей, от положения звезд на небе. 
Единственное что можно точно сказать - затраты на сбор мусора (во время работы функции) в тестовом приложении будут совершенно не такими, как затраты на сбор мусора (во время работы функции) в хоть каком-то живом приложении. =>
Часть реализации функции в тестовом приложении будет вести себя не так, как в живом. Здоровая такая часть. Совсем не так. 


А почему только первый? а как же учет кэширования и предсказания переходов в процессоре? а как же кэширование, которое довольно долго будет устаканиваться?
Предлагаю отбрасывать первых 10 миллионов вызовов. И проводить тестирование в комнате с искуственным климатом. И считать достаточно точными результаты, полученные на 2-3 неделе непрерывной работы.