% time {set RE {.*}}
11 microseconds per iteration
% time {set RE {.*}} 10
1.4 microseconds per iteration
% time {set RE {.*}} 100
0.49 microseconds per iteration
% time {set RE {.*}} 1000
0.422 microseconds per iteration
What could be the reason for this? I would have expected roughly the same
figures for all the timings.
Thanks,
Francois
The reason behind this "oddity" is that Tcl can't give you exact numbers
for execution time of commands with [time]. What [time cmd count] does,
instead, is
a) start the timer
b) loop $cmd $counter time
c) stop the timer
d) calculate time difference and divide with $counter
So when you run timings with [time] you aren't getting back a number of
counter*exec_time, but (overhead+count*(loop_overhead+exec_time))/count.
I'll do some math with you, to explain.
What we have here is a function f(a,b,c,d)=a+b(c+d)=~a+be and four values.
So this thing is solvable even by mere mortals, such as me. As precision
and statistics try to make this harder, we'll start solving from the
bigger counts.
a+1000e=422, 10a+1000e=49, 9a=68, a=~7.556
1000e=414.444, 100e=41.444, 900e=373, e=~0.414
Unfortunately, e(c,d)=c+d can't be really solved from this information, so
we can't dissect loop_overhead and exec_time. This will create some minor
loss of precision. But now we can loop b through {1000 100 10 1} and take
a look what we should get from (a+b*e)/b:
b=1000, (7.556+1000*0.414)/1000= 0.422
b=100, (7.556+100*0.414)/100 = 0.490
b=10, (7.556+10*0.414)/10 = 0.170
b=1, 7,556+0.414 = 7,970
and be amazed, not. The minor fluctuation from not being able to negate
effect of loop_overhead seems to put these calculations into state of no
use. But this should still give you some information why there really is
no oddity in your timings :)
Sorry for long post.
--
-Kaitzschu
s="TCL ";while true;do echo -en "\r$s";s=${s:1:${#s}}${s:0:1};sleep .1;done
Thanks a lot for your crystal clear explanation. I learned something today!
> Sorry for long post.
Your long post contain lots of useful information and was a pleasure to
read.
Thanks again.
Francois