Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Commands faster/slower in a counted DO loop

May
13,802
211
I've been testing three timing mechanisms. Standing alone, they're about the same speed. In a counted DO loop, the first iteration is a little faster speed and the subsequent iterations are lot faster. I'm curious about what's going on. I've done these many times; these results are typical.

Code:
v:\> qton & qtoff
0.000437

v:\> do i=1 to 5 (qton & qtoff)
0.000327
0.000107
0.000105
0.000104
0.000106

v:\> clock 1 zon & echo %@clock[1,s,0,r]
0.000415

v:\> do i=1 to 5 (clock 1 zon & echo %@clock[1,s,0,r])
0.000332
0.000108
0.000105
0.000105
0.000103

v:\> timer /1 /q on & echo %@timer[1,us]
415 us

v:\> do i=1 to 5 (timer /1 /q on & echo %@timer[1,us])
336 us
108 us
107 us
105 us
105 us
 
Likely due to initialization overhead?! Then subsequent iterations seem stabilized.

So the first run would includes overhead (e.g., loading and setting up the clock), but subsequent runs are optimized.
 
Likely due to initialization overhead?! Then subsequent iterations seem stabilized.

So the first run would includes overhead (e.g., loading and setting up the clock), but subsequent runs are optimized.
DO knows nothing about any clock.
 
Hmmm ... CPU optimization or caching?

Probably Rex only can explain that.
 
The first run has all of the interactive command line parsing overhead. Subsequent runs in the loop do not.

And no, I'm not going to post the 15K+ lines of the parser code. But there's a LOT going on you don't know about (and shouldn't care about, unless it goes wrong!).
 
The first run has all of the interactive command line parsing overhead. Subsequent runs in the loop do not.
I'm not timing anything outside the loop or even the loop itself, only what happens between TIMER being called and @TIMER being expanded.

Code:
v:\> do i=1 to 5 (clock 1 zon & echo %@clock[1,s,0,r])
0.000332
0.000108
0.000105
0.000105
0.000103
 
Here's the command.

Code:
v:\> do i=1 to 5 (clock 1 zon & echo %@clock[1,s,0,r])

The timing starts when the CLOCK command is executed. Then it's got to figure out what to do next. Are you saying that at the command line, inside the DO loop, more is done before @CLOCK is expanded than in a BTM, inside the DO loop?
 
Here's the command.

Code:
v:\> do i=1 to 5 (clock 1 zon & echo %@clock[1,s,0,r])

The timing starts when the CLOCK command is executed. Then it's got to figure out what to do next. Are you saying that at the command line, inside the DO loop, more is done before @CLOCK is expanded than in a BTM, inside the DO loop?

Yes, that's what I'm saying. If you had a single command inside the DO loop, the difference would be minor. But you have two commands, so the parser is doing extra work.
 
Back
Top