testtimer за работой
Рассмотрим некоторые API-функции, используемые тестовыми программами для измерения интервалов времени.
GetTickCount. Самая популярная функция. Возвращает кол-во миллисекунд, прошедших со времени последнего старта системы. В зависимости от типа установленного ядра использует либо PIT-, либо APIC-таймеры, в соответствии с чем ее разрешение составляет либо 10 мс, либо 15 мс, причем, некоторые тики таймера могут быть пропущены (т. е. за 30 мс не произойти ни одного увеличения счетчика). Не рекомендуется к употреблению.
GetSystemTime. Возвращает истинное время. То есть функция думает, что оно истинное, а в действительности – производное от системного счетчика, инкрементируемого каждые 10 мс или 15 мс за вычетом "съеденных" тиков и врожденной неравномерности хода PIT и APIC-таймеров. Периодически синхронизует себя с часами реального времени, а если запущена специальная Интернет-служба, то еще и с атомными часами, т. е. системное время продвигается траекторией пьяного гонщика, едущего по пересеченной местности. Для измерений временных промежутков непригодна.
timeGetTime. Тоже самое, что и GetTickCount. Документация утверждает, что разрешающая способность этой функции составляет 1 мс, в действительности же – 10 мс. Синхронные изменения timeGetTime и GetTickCount подтверждают, что они запитаны от одного источника.
Sleep. Усыпляет поток на указанное количество миллисекунд, задерживая на время управление. Теоретически может использоваться для калибровки других таймеров и вычисления коэффициента перевода таковой процессора в секунды. Практически же… Время ожидания принудительно округляется до величины, кратной "тику" основного системного таймера, причем на момент выхода из сна, данный поток должен находится в самом начале очереди потоков, ожидающих выполнения, в противном случае ему придется подождать. Может быть доли секунды, а может несколько минут – все зависит от размеров очереди, а она непостоянно. На хорошо загруженной системе, поток, планирующий вздремнуть 100 мс рискует проснуться… через минуту!
QueryPerfomanceCounter. Возвращает количество тиков наиболее точного таймера, прошедших с момента старта системы или… его последнего переполнения. Является переходником к функции KeQueryPerfomanceCounter, реализованной в HAL'е. Windows XP поддерживает HPET, более ранние системы нет. Если HPET аппаратно доступен и программно поддерживается, используется он, в противном случае ACPI-ядра будут использовать PM, а не ACPI – либо PIT, либо возвратят ноль, сигнализируя об ошибке. Для определения продолжительности одного тика можно использовать функцию QueryPerformanceFrequency, возвращающую его частоту в герцах. Это самая лучшее средство для профилировки и хронометража времени из всех имеющихся, однако, как уже говорилось, PM-таймеры могут идти неточно или совершать неожиданные прыжки вперед, поэтому, показания, возращенные QueryPerfomanceCounter требуют некоторой обработки.
