* Erik Leunissen <lo...@the.footer.invalid>
| Please see below how [after] consumes way more time than requested.
| Observed on Windows 7.
>
| (Under Linux, the time command returns the expected value of around 10000 microseconds per iteration.)
>
| Can others reproduce this?
No :-)
% parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(engine) = Tcl
tcl_platform(machine) = amd64
tcl_platform(os) = Windows NT
tcl_platform(osVersion) = 10.0
tcl_platform(pathSeparator) = ;
tcl_platform(platform) = windows
tcl_platform(pointerSize) = 8
tcl_platform(threaded) = 1
tcl_platform(user) = ralf
tcl_platform(wordSize) = 4
% info patchlevel
8.6.11
% time {after 10} 100
10994.358 microseconds per iteration
% time {after 11} 100
11957.325 microseconds per iteration
% time {after 12} 100
13060.527000000002 microseconds per iteration
% time {after 13} 100
13998.957000000002 microseconds per iteration
% time {after 14} 100
14994.269000000002 microseconds per iteration
% time {after 15} 100
15938.196000000002 microseconds per iteration
Off-by-one, 'but'... :-)
| Can someone explain it?
Others already have explained that your observation is the result of the
default 15ms timer granularity on Windows.
If you are able to compile binary extensions, this code will do the
above trick:
#undef WIN32_LEAN_AND_MEAN
#include <windows.h>
TIMECAPS tc;
if (MMSYSERR_NOERROR != timeGetDevCaps(&tc, sizeof(tc))
|| TIMERR_NOERROR != timeBeginPeriod(tc.wPeriodMin)) {
error("cant set timeBeginPeriod()");
return;
}
References:
https://docs.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timegetdevcaps
https://docs.microsoft.com/en-us/windows/win32/api/timeapi/ns-timeapi-timecaps
https://docs.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod
HTH
R'