I just found something odd that may be related to the max/min problem
that was recently discovered. It was triggered by the following loop:
for i=1:10
tic
(long simulation)
toc
end
The long simulation was a bit-error-rate Monte Carlo simulation that
uses David Bateman's bchenco and bchdeco functions from octave-forge.
It is called inside a lower-level function. The timing result was that
the first run was always about 30% faster than subsequent runs. The
first time I saw this I thought it was a coincidence due to external
CPU load factors, but I have now observed it repeatedly. My experience
is also consistent with the other comments--stopping the script and
restarting gives the slower run time, while restarting octave or
"clear all" give the fast run time the first time through. Like max
and min, bchenco and bchdeco are in the same .oct file.