On Fri, 10 Mar 2000 10:05:14 +1300, you wrote:
>Luke,
>
>See "QueryPerformanceCounter" & "QueryPerformanceFrequency" in the
>Delphi/Windows help files - it is the high high-resolution performance
>counter functions - these may or may not work on your machine.
These are the best timers to use to measure short duration elapsed time (for
win32) on an arbitrary system.
The general resolution of these is in the order of microseconds.
GetTickCount is one of the worst (excluding getting the Time of Day).
While the units of the returned value is milliseconds, the resolution is about
10 milliseconds. Check this by reading GetTickCount in a loop and watch how the
values change. OK for use if you want to time something that you repeat lots of
times, but why bother ....
>
>As far as I know, these are "real" time counters and not elasped process
>time counters - which is what you need in this case I believe.
Correct, subtracting one from another gives elapsed.
What they will not do is allow you to delay for a time (except by spinning
waiting for a specific amount of time to elapse - as is done in linux).
IF you can guarantee that the target system is a Pentium (or later), the CPU
Cycle counter can be read via RDTSC ...
>
>The other comments made still apply. I believe the TZProfiler stuff is from
>the Delphi Super Page and it uses the pentium RDTSC (Read Time Stamp
>Counter) instruction.
This gives a resolution of whatever your CPU core is (e.g.: 500MHZ clock =
resolution of 2 nano seconds). Even better is that obtaining the counter value
is pretty good - by memory, 18 CPU clock cycles the last time I checked (Pentium
200 non-mmx), excluding doing anything with the value obtained.
I have some small routines that use this to return elapsed times (including
determining CPU clock speed by calibrating CPU counters against QueryPerformance
Counters). Source available.
>
>In all cases the test should be repeated something like 1000 to 10000 or
>more times to give an average. This will give you the shortest and average
>times. Also in this case watch out for what other processes are doing at the
>same time and the effects of any disk caching. Most disks sport access times
>from about 5ms to 12ms these days, any faster times will be due to caching
>of blocks/read ahead by controllers.
It very much depends on what you are timing. I have used low repeat counts with
good confidence. This allows, for example, comparisons of the time it takes to
do something the first time, against the time it takes to do it again (once
things are cached). With high repeat counts, you can't make the distinction.
If your task involves doing things mostly once, it's handy to know the different
figures.
NT and W95/98 do go "out to lunch" for short periods every tick (and
occasionally for longer). For timing short duration events (e.g.: sub
millisecond) these (if you hit one) are blindingly obvious as they are not
repeatable.
>
>Timing Disk accesses is almost a specialised science on the Win32 platform.
Performance measurement is, on any platform.
>
>Myles.
>
>> -----Original Message-----
>> From: Luke Pascoe [SMTP:[EMAIL PROTECTED]]
>> Sent: Friday, 10 March 2000 09:40
>> To: Multiple recipients of list delphi
>> Subject: [DUG]: Timing less than 1ms
>>
>> I'm timing some disk access, and I need a division of time less than 1
>> millisecond (GetTickCount)
>>
>> Is there any way to do this?
>>
>> Luke Pascoe
>> Programming
>> Ihug
--
Peter S Ingham [EMAIL PROTECTED]
Lower Hutt, New Zealand
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
