Re: alternative to gettickcount
- From: "Karl E. Peterson" <karl@xxxxxxxx>
- Date: Wed, 7 Nov 2007 17:08:45 -0800
Mike Williams wrote:
I think everyone knows that technique (waiting for a change in the clock
before proceeding with a timing test). It's almost an "industry standard"
and I'm sure it is what many people do, even in the kitchen when they are
timing baking periods for steak and kidney pies!,
Sorry, no offense. Just threw it in for the thread's sake. <g>
but it will NOT cut the
error in half, as you have suggested.
Yeah, that's what I get for multitasking. My mistaken impression offered.
How on earth did you arrive at that [must use timeBeginPeriod at least
a dozen milliseconds before calling timeGetTime?] I've never heard of
this.
Well I don't know what system you are running Karl, but in general you need
to accept the fact that on many (probably most) Windows systems the
resolution of timeGetTime does NOT default to one millisecond.
Right. It's an XP system at the moment, and the resolution appears to be the
bog-standard ~15.something milliseconds:
Public Sub Main()
Dim e1 As Long, e2 As Long
Dim n
' Call timeBeginPeriod(1)
e1 = timeGetTime
Do
e2 = timeGetTime
If e1 <> e2 Then
Debug.Print e2 - e1
e1 = e2
n = n + 1
End If
Loop While n < 5
End Sub
Returns:
16
15
16
16
15
In fact on
many machines it is something of the order of 5 or 10 milliseconds or so. In
Win95 it is one millisecond, and it also appears to be one millisecond in
Vista (from my own experience) but in other versions (NT/2K/XP I think) it
is something in the region of five milliseconds, or perhaps more. I can't
remember what it is in Win98.
Me either. I know it varies.
My suggestion of "a dozen milliseconds" was
of course just a "tongue in cheek" remark, but what I meant is that you
should set the resolution *and allow the new resolution to lock into place*
before you begin timning, so a dozen milliseconds seemed to fit the bill!
Uncommented the timeBeginPeriod above, and these are the new results:
15
16
1
1
1
Interesting! I need to update my stopwatch class.
The other point (which I alluded to in my earlier post and to which you seem
to have taken offence) is that in systems where timeBeginPeriod is necessary
you need to do it *before* you begin timing.
No offense taken, either. I agree, of course, with this point.
For example, on a system where
the default resolution of timeGetTime is 5 or perhaps 10 milliseconds and
you do:
Dim t1 As Long, t2 As Long
timeBeginPeriod 1
t1 = timeGetTime
' some code here
t2 = timeGetTime
. . . you will NOT get a resolution of one millisecond for the timed code.
That's why I said you need to use timeBeginPeriod some milliseconds *before*
you begin the timing period, to allow the new resolution to "click into
place" before the timed code begins.
Agreed. I'm gonna stick a Do-Loop into my class, much like the above.
In your own specific case where you
have said that you always "wait for a new clock" before you begin the timed
code then of course it will usually be okay,
Not really. Note that in my test, here, it was actually the third change where the
new resolution kicked in.
but in cases where you do not
do that then you will get an error in the result. So, my own suggestion of
using timeBeginPeriod in the Form Load event (or whatever event runs at
startup) is a good one, and I stick by it.
You Brits crack me up sometimes. :-)
You can argue with me if you like
(I often enjoy a good argument) but please don't "look down on me", as you
appear to have done in your own response, and don't say things like "How on
earth did you arrive at that? I've never heard of this". You'll only get my
back up ;-)
Actually, you really caught me off-guard there. (Read it as a exclamatory statement
of surprise, more than an accusatory "wtf, man?") Makes sense, on reflection, but I
thought I'd been around all the issues I'd have to have dealt with, a good decade or
more ago. Like I said, no offense intended or taken. We're all here to learn, eh?
Thanks... Karl
--
..NET: It's About Trust!
http://vfred.mvps.org
.
- Follow-Ups:
- Re: alternative to gettickcount
- From: Robert Morley
- Re: alternative to gettickcount
- From: Mike Williams
- Re: alternative to gettickcount
- From: Karl E. Peterson
- Re: alternative to gettickcount
- References:
- RE: alternative to gettickcount
- From: KeetClassic
- Re: alternative to gettickcount
- From: Ulrich Korndoerfer
- Re: alternative to gettickcount
- From: Mike Williams
- Re: alternative to gettickcount
- From: Karl E. Peterson
- Re: alternative to gettickcount
- From: Mike Williams
- RE: alternative to gettickcount
- Prev by Date: Re: Call a Procedure in another form module
- Next by Date: Re: alternative to gettickcount
- Previous by thread: Re: alternative to gettickcount
- Next by thread: Re: alternative to gettickcount
- Index(es):
Relevant Pages
|
Loading