From maintainers-request at octave dot org Wed Feb  2 16:00:21 2005
Subject: Re: More on slow min function
From: Daniel J Sebald <daniel dot sebald at ieee dot org>
To: Quentin Spencer <qspencer at ieee dot org>
Cc: maintainers at octave dot org
Date: Wed, 02 Feb 2005 16:06:36 -0600

Quentin Spencer wrote:

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


I think you are right, Quentin.  We looked at loops comprised mainly of 
min/max (multiple factor loss).  You likely have more code in your loops 
with the occasional call to bchenco/bchdeco (fractional loss).  Confirms 
the problem.

Thanks,

Dan