Написаны макросы для замера производительности отдельных участков кода и вывода результатов в файл. Используется функция QueryPerformanceCounter.
Выводится:
— общее время выполнения участка кода
— количество раз, которое выполнялся участок кода
— среднее время работы участка кода
Пример использования:
DECLARE_PERFORMANCE_FILE_STREAM(F:\\finish_dos_point_perf.log, perfFile);
DECLARE_PERFORMANCE_CHECKER(1, perfFile);
START_PERFORMANCE_CHECK(1);
// участок номер 1 для замера
FINISH_PERFORMANCE_CHECK(1);
DECLARE_PERFORMANCE_CHECKER(2, perfFile);
START_PERFORMANCE_CHECK(2);
// участок номер 2 для замера
FINISH_PERFORMANCE_CHECK(2);
Здравствуйте, VNG, Вы писали:
VNG>Написаны макросы для замера производительности отдельных участков кода и вывода результатов в файл. Используется функция QueryPerformanceCounter.
тоже этими функциями пользовался пока не понадобилось знать точно скока именной мой процесс/поток пожирает. начал пользоваться другими, точность такого же высокого уровня, правда седует уточнить
Get{Process|Thread}Times
Здравствуйте, VNG, Вы писали:
VNG>Написаны макросы для замера производительности отдельных участков кода и вывода результатов в файл. Используется функция QueryPerformanceCounter. VNG>Выводится: VNG>- общее время выполнения участка кода VNG>- количество раз, которое выполнялся участок кода VNG>- среднее время работы участка кода
[]
Я б добавил бы сюда:
HANDLE hProcess = GetCurrentProcess();
SetPriorityClass(hProcess, REALTIME_PRIORITY_CLASS);
// run tests
// set priority back normal
SetPriorityClass(hProcess, NORMAL_PRIORITY_CLASS);
хотя, конечно же, юзер может это сделать сам если захочет.
Здравствуйте, korzhik, Вы писали:
K>Здравствуйте, VNG, Вы писали:
VNG>>Написаны макросы для замера производительности отдельных участков кода и вывода результатов в файл. Используется функция QueryPerformanceCounter. VNG>>Выводится: VNG>>- общее время выполнения участка кода VNG>>- количество раз, которое выполнялся участок кода VNG>>- среднее время работы участка кода
K>[]
K>Я б добавил бы сюда: K>
K> HANDLE hProcess = GetCurrentProcess();
K> SetPriorityClass(hProcess, REALTIME_PRIORITY_CLASS);
K> // run tests
K> // set priority back normal
K> SetPriorityClass(hProcess, NORMAL_PRIORITY_CLASS);
K>
K>хотя, конечно же, юзер может это сделать сам если захочет.
вот как раз для избежания этих неточностей желательно использование GetProcessTimes и GetThreadTimes
иначе точность малая при телодвижениях других процессов
MS>>А зачем использовать плавающую точку в целочисленной задаче?
VNG>Ну здесь я рассуждал просто. Чтобы не потерять значимое время в случае, когда кусок кода выполняется очень много раз.
Получилось как раз наоборот:
— От Windows ты получаешь 64 битовое число, которое в общем случае нельзя представить 64 битовым double.
— При суммировании чисел типа double происходит накопление ошибки. Ошибка тем более значимая, чем чаще выполняется код.
При суммировании целочисленных типов (например INT64) ошибки накопления исключены.
Ну так можно сказать, что любая программа или библиотека есть ничто иное как набор велосипедов с различной формой колес, собраннх вместе, обработаных напильником и скомпонованных вместе.
T>Время жизни этого формума можно мерить по очередным "изобретениям" QueryPerformanceCounter
QueryPerformanceCounter я не изобретал. Внимательно читаем шапку первоначального поста.
Пользоваться твоими макросами неудобно. Я бы предпочёл иметь класс, в котором конструктор принимает номер (имя было бы предпочтительнее) участка и сразу же начинает измерение, а в деструкторе его заканчивает. Ну и конечно же неплохо было бы иметь возможность останавливать-запускать измерение времени конкретным экземпляром класса. По крайней мере, в своём велосипеде я так делал
Здравствуйте, Left2, Вы писали:
L>Пользоваться твоими макросами неудобно.
Так я и не особо претендовал. Просто изложил идею. Для моей локальной задачи нахождения боттл-нек в нескольких функциях это было оптимальное решение.
L> Я бы предпочёл иметь класс, в котором конструктор принимает номер (имя было бы предпочтительнее) участка и сразу же начинает измерение, а в деструкторе его заканчивает. Ну и конечно же неплохо было бы иметь возможность останавливать-запускать измерение времени конкретным экземпляром класса. По крайней мере, в своём велосипеде я так делал
Можно и такой огород городить:
class perf_singleton
{
std::map<std::string, perf_info> m_info;
public:
static perg_singleton & instance();
void update(std::string const & blockName, _int64 time);
voit put_to_stream(std::ostream & stream);
};
class perf_counter
{
public:
perf_conter(std::string const & blockName);
~perf_counter()
{
perf_singleton::instance().update(m_blockName, m_time);
}
};
int main()
{
{
perf_counter counter("block1");
// some portion of code
}
{
perf_counter counter("block2");
// another portion of code
}
perf_singleton::instance().put_to_stream(std::cout);
}