ちょっと待機時間を設けよう。処理の時間計測をしよう。
そんなことはちょいちょいありますよね。
しかし、そのタイマーがこっそり変な動きをしていることがあります。
それはその機能の精度が原因です。
ダメな例
Sleepという、いかにもなWindows APIがあります。
宣言は以下
void Sleep(
[in] DWORD dwMilliseconds
);
引数に待機時間をミリ秒単位で指定できます。
実験
Sleepが何ミリ秒スリープできているか、確認してみます。
for (int i = 0; i < 10; i++)
{
FILETIME startFileTime = { 0 };
::GetSystemTimePreciseAsFileTime(&startFileTime);
::Sleep(1);
FILETIME endFileTime = { 0 };
::GetSystemTimePreciseAsFileTime(&endFileTime);
ULONG64 startTime = startFileTime.dwLowDateTime + ((ULONG64)startFileTime.dwHighDateTime << 16);
ULONG64 endTime = endFileTime.dwLowDateTime + ((ULONG64)endFileTime.dwHighDateTime << 16);
printf("%llu\r\n", endTime - startTime);
}
10連続で、Sleepにかかった時間を計測して見ます。自分の環境では以下の結果となりました。
FileTimeは単位が100ナノ秒なので、ミリ秒に直すと4ms～15msがSleep(1);にかかった時間ということになります。
回答
SleepのMSDNのページに回答はあります。
システムクロックが一定間隔で行われ、そのtickをSleep時間のチェック基準としています。tickの発生間隔が長いほど、その精度が悪くなるということです。
tickの頻度を上げるためにtimeBeginPeriodというWindows APIが提供されています。
実験
for (int i = 0; i < 10; i++)
{
::timeBeginPeriod(1);
FILETIME startFileTime = { 0 };
::GetSystemTimePreciseAsFileTime(&startFileTime);
::Sleep(1);
FILETIME endFileTime = { 0 };
::GetSystemTimePreciseAsFileTime(&endFileTime);
::timeEndPeriod(1);
ULONG64 startTime = startFileTime.dwLowDateTime + ((ULONG64)startFileTime.dwHighDateTime << 16);
ULONG64 endTime = endFileTime.dwLowDateTime + ((ULONG64)endFileTime.dwHighDateTime << 16);
printf("%llu\r\n", endTime - startTime);
}
結果は以下
1.5ms～1.9msになったので、大分マシになりましたね。
注意喚起
timeBeginPeriodを使っておけば良いというわけではありません。
Sleepのページの注意書きにもある通り、システムクロック、システム電力使用量、スケジューラーに大きな影響を与えるためです。
おまけ
Sleep(0);の場合は、タイマー精度を変更しなくても、ほぼ0msの待機になります。
Sleep(0);は0ms待機という目的で使われるわけではなく、別スレッドにタイムスライスを譲るという意味合いだからです。
その他精度が低いやつ
-
GetTickCount64
- システムが開始されてから経過したミリ秒数を取得
-
timeGetTime
- システム時刻をミリ秒単位で取得
タイマーの結果がなんか変だな、と思った方の役に立てれば幸いです。
用途によって、使い分けて行きましょう。