More on slow min function

[Quentin Spencer]

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.