Решил сразу к вам обратиться, но тему можно и в дотнет снести.
Странная ситуация: имеется с десяток регулярных выражений, начал играться с RegexOptions.Compiled. Запуская программу отдельно с RegexOptions.Compiled получаю около ~6 сек на отладочных файлах, без этой опции -- ~5.75 сек. Запустил в цикле до 10 итераций для 13 файлов -- 54 сек. vs 56 сек. в пользу некомпилированных регулярок.
Запуская профайлер в комбинациях (Line by line,Tracing)*(Thread cycle time,Wall time,Wall Time CPU instr.) наблюдается преимущество в среднем 5% версии с Compiled, что логично на мой взгляд.
Вопрос, чему верить -- живым прогонам или профайлеру? Профайлер вообще для подобных замеров имеет смысл использовать?
Упдате: вопрос снят, ибо при скомпилированных регулярках приложение видимо чуть дольше грузится, что и дает разницу. Если их стартовать вручноую (после какого-нибудь Console.ReadLine), то compiled версия явно быстрее. Использовал режим tracing и thread cycle time.
В Вашем случае, для замера времени выполнения конкретного метода можно пользоваться простым Stopwatch'ем, а не профайлером. Профайлер неизбежно вносит погрешность в измерения и его использование оправдано, например, если Вас интересует распределение времени выполнения по дочерним вызовам, либо если Вы хотите измерить время сразу для нескольких методов.
Если всё же использовать dotTrace для сравнения времени выполнения одного метода, то для выбора режима профилирования нужно понимать следующее:
— точность измерения времени выполнения метода в режиме Tracing уменьшается по мере увеличения общего количества вызовов в поддереве этого метода. Это связано с тем, что в режиме Tracing профайлер выполняет некоторые действия на каждый вызов метода, и при этом он лишь частично компенсирует эту погрешность.
— абсолютная погрешность измерения времени одного вызова метода в режиме Sampling: 20 ms. Это связано со статистическим характером сэмплинга: dotTrace сэмплирует каждый поток с частотой 100 сэмплов/сек. Соответственно, относительная погрешность сэмплинга уменьшается по мере увеличения исследуемого времени выполнения.
— режим Line-by-Line вносит наибольшую инструментальную погрешность в измерения.
В итоге, если в поддереве исследуемого метода не происходит большого количества вызовов других методов (например, их меньше 1000), то можно пользоваться Tracing'ом. Если же вызовов много, то лучше увеличить количество итераций цикла и использовать Sampling.
Здравствуйте, Anatoly Nikitin, Вы писали:
AN>Здравствуйте, Sharov,
AN>В Вашем случае, для замера времени выполнения конкретного метода можно пользоваться простым Stopwatch'ем, а не профайлером. Профайлер неизбежно вносит погрешность в измерения и его использование оправдано, например, если Вас интересует распределение времени выполнения по дочерним вызовам, либо если Вы хотите измерить время сразу для нескольких методов.
AN>Если всё же использовать dotTrace для сравнения времени выполнения одного метода, то для выбора режима профилирования нужно понимать следующее: AN>- точность измерения времени выполнения метода в режиме Tracing уменьшается по мере увеличения общего количества вызовов в поддереве этого метода. Это связано с тем, что в режиме Tracing профайлер выполняет некоторые действия на каждый вызов метода, и при этом он лишь частично компенсирует эту погрешность. AN>- абсолютная погрешность измерения времени одного вызова метода в режиме Sampling: 20 ms. Это связано со статистическим характером сэмплинга: dotTrace сэмплирует каждый поток с частотой 100 сэмплов/сек. Соответственно, относительная погрешность сэмплинга уменьшается по мере увеличения исследуемого времени выполнения. AN>- режим Line-by-Line вносит наибольшую инструментальную погрешность в измерения.
AN>В итоге, если в поддереве исследуемого метода не происходит большого количества вызовов других методов (например, их меньше 1000), то можно пользоваться Tracing'ом. Если же вызовов много, то лучше увеличить количество итераций цикла и использовать Sampling.
Про инструментальную погрешность понятно, благодарю. Но я сравнивал время работы программы над файлом в цикле. И мне казалось, что Line-by-Line даст наиболее точный результат ибо использует инструментирование + соотв. регистры процессора.
