Может кто-то расшифровать, имеет ли timeGetTime () или QueryPerformanceCounter / QueryPerformanceFrequency более низкие издержки и / или точность?

Question

Идея состоит в том, что существующий проект довольно часто использует timeGetTime () (для целей Windows).

milliseconds = timeGetTime();

Теперь это можно заменить на

double tmp = (double) lpPerformanceCount.QuadPart/ lpFrequency.QuadPart; 
milliseconds = rint(tmp * 1000);

с lpPerformanceCount.QuadPart и lpFrequency.QuadPart, взятыми из использования одного вызова QueryPerformanceCounter () и QueryPerformanceFrequency ().

Я знаю, что внутреннее устройство Windows - своего рода вуду, но может кто-нибудь расшифровать, какое из этих двух значений более точное и / или имеет больше накладных расходов?

Я подозреваю, что точность может быть такой же, но QueryPerformanceCounter может иметь меньше накладных расходов. Но у меня нет точных данных, чтобы подтвердить это.

Конечно, я не удивлюсь, если все наоборот.

Если накладные расходы незначительны, меня больше интересует, есть ли разница в точности.

Answer 1

Точность timeGetTime () является переменной в зависимости от последнего использованного timeBeginPeriod. Это никогда не будет лучше, чем одна миллисекунда. QueryPerformanceCounter также является переменной величиной, в зависимости от аппаратной поддержки. Это никогда не будет хуже, чем около микросекунды.

Ни у одного из них нет заметных накладных расходов, QPC, вероятно, немного тяжелее. Является ли это важным для вас, неясно из вашего вопроса. Я сомневаюсь в этом, но мера. С QPC.

Answer 2

Мы обновили документацию для QueryPerformanceCounter, и это должно помочь ответить на вопросы выше. Пожалуйста, смотрите

http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx

Эд Бриггс Microsoft Corporation

Answer 3

Точность лучше на QPC. timeGetTime является точным в диапазоне 1-10 мс (и его разрешение не более 1 мс), тогда как QPC может дать вам точность в микросекундном диапазоне.

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

Но ни тот, ни другой не слишком дорогой. Если вы не собираетесь вызывать таймер миллионы раз в секунду, накладные расходы незначительны для обоих.

Answer 4

Будьте осторожны: QueryPerformanceCounter может зависеть от процессора.Если ваш поток захватывает счетчик производительности на одном процессоре и останавливается на другом процессоре, прежде чем снова захватить, результаты могут быть ненадежными.См. MSDN запись .

Answer 5

QueryPerformanceCounter не совсем дает вам время.Чтобы преобразовать его значения во временные измерения, вы должны будете использовать QueryPerformanceFrequency, который должен дать вам знать, с какой скоростью увеличивается счетчик.Но значение частоты более или менее приблизительное.Частота счетчика может варьироваться в зависимости от используемого оборудования и версии ОС.Но это не должно считаться постоянным.Он имеет смещение и иногда сопровождается тепловым дрейфом.Сказав это, я бы рекомендовал использовать QueryPerformanceCounter с осторожностью.

Некоторые все еще смешивают accuracy с granularity.QueryPerformanceCounter имеет более высокую степень детализации, а timeGetTime обладает большей точностью.

Однако самый быстрый источник - GetSystemTimeAsFileTime, который возвращает значение времени в 100 нс.Но его гранулярность составляет , а не 100 нс.Его гранулярность зависит от результата timeGetDevCaps и значения timeBeginPeriod .Правильная установка последнего может привести к гранулярности около 10000, что соответствует около 1 мс.

Я написал более подробную информацию здесь .