Re: time command oddity exists not

On Mon, 28 Nov 2005, Francois Vogel wrote:

% 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.

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
.

Relevant Pages