набросал на скорую руку


есть более правильные\точные способы?

http://msdn.microsoft.com/en-us/library/sy...iagnostics.aspx по словам Perfomance поищите.
А если разово, то есть профайлеры

и что я там найти должен?

попробуйте поискать на странице Perfomance и ПОЧИТАТЬ ссылки на ней же по данным поиска.

Это сообщение отредактировал(а) jonie - 18.6.2010, 18:11

поискал. потыкал ссылки. что дальше?

мне надо сравнить производительность различных функций\методов, я хз как мне эти ссылки помогут

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

jonie, покажите пример, и напишите чем он лучше кода в 1м посте

http://www.codeproject.com/KB/dotnet/perfcounter.aspx
лучше тем что не велосипед.

Это сообщение отредактировал(а) jonie - 21.6.2010, 10:36

я в этой статье нашел только один вменяемый кусок кода, и он начинается с 

это знаете ли даже не смешно %)

Если я сам запускаю код N раз, то я знаю сколько раз этот код отработал. Зачем мне еще какой-то счетчик PerformanceCounter ???

Abyx, ну вот, ты и ответил на свой вопрос.
PerformanceCounter-ы нужны для мониторинга производительности кусков цельного приложения, а не сферической функции в вакууме. Если функция не тормозит на одном вызове - нет смысла ее "оптимизировать". И уж точно нет смысла замерять время ее работы точнее чем stopwatch-ем.

Abyx, производительность это не только "моя функция обработала за 2 сек" - такие функции можно профилировщикам скормить.

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

Жесть какая-то %)
У меня есть конкретная задача, и я спрашиваю как ее решить. Если вы не знаете как ее решить - валите из этой темы, а не пишите про "более интересные задачи".

!  PashaPash

Симметричный ответ - или сформулируй запрос, или вали на форум с пользователями-телепатами

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

!  PashaPash

Hint of the day: Сообщения от других пользователей могут быть не просто флудом, но еще и настоящими ответами на твой вопрос.

Я в курсе что такое производительность. 
А вот вы похоже не в курсе что такое читать чужие посты.

Вы что, предлагаете взять мои 5-6 функций которые мне надо сравнить, каждую руками прогнать через профилировщик, записать результаты на бумажку и сравнивать?


Создайте свою тему, и там пишите о том что вам интересно.



Это сообщение отредактировал(а) PashaPash - 23.6.2010, 13:40

Abyx, у тебя какие-то проблемы с чтением чужих постов? 

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

Потому что толку от тестирования изолированной функции - 0. Тем более что такой метод тестирования будет давать дикий разброс в зависимости даже от конфигурации приложения, не говоря уже о таких мелочах как объем памяти, режим сборки мусора и количестве ядер.

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

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

PashaPash, вопрос был задан в названии темы и 1м посте. Чтобы его понять, никакой телепатии не надо.
Повторю еще раз:
    Как замерить производительность реализации алгоритма (функции\подпрограммы\etc)

Все ответы не относящиеся к этому вопросу, пожелания чем мне следует заниматься и т.п. - есть оффтоп.

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

Я знаю зачем мне это надо.

А вы тут флудите и пишете вещи, не относящиеся к заданному мной вопросу. =\

Добавлено через 2 минуты и 46 секунд
для тех кто в танке, и прочих ***, System.Diagnostics.Stopwatch.ElapsedTicks и kernel32.QueryPerformanceCounter - это одно и то же

то ли у меня что-то  со зрением, то ли в первом посте такого вопроса нет. в первом посте есть вопрос "вот код, вызывающий 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 неделе непрерывной работы.

Предлагаю вам перестать предлагать всякий бред.

Встречное предложение - предлагаю вам перестать заниматься бесполезной фигней.

PashaPash, это не ваше дело, чем мне заниматься.
Перестаньте писать в этой теме, если она вам бесполезна.

Abyx, это не твое дело, чем мне заниматься. твое дело - не оффтопить, и спокойно воспринимать советы, раз уж спросил в разделе для новичков.

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

Тема закрыта из-за неспособности автора понять чужие сообщения.