Re: min function very slow?

[Daniel J Sebald]

John W. Eaton wrote:

> With ignore_fucntion_time_stamp = "all", you tell it to not check to
> see if the function is out of date.  But there could still be some
> significant overhead to look it up the first time.  It is odd that
> searching for a function would take more time when it can be found in
> a shared library that is already loaded, but that seems to be what is
> happening.  In any case, I don't think this has anything to do with
> min or max since you can get similar results with other functions that
> are defined from the same .oct file.  Also, try switching the order of
> the calls to min and max in your script and run it again in a freshly
> started Octave session and you should see that the second function
> loaded is the slower one.
>  

Oh, here is another bit of information you may have not seen: 'clear' on 
*both* function names seems to fix the problem temporarily.

octave:2> [loopt, mint, maxt] = mmt2(1000)
loopt = 0.0089990
mint = 0.042994
maxt = 6.1801
octave:3> clear min
octave:4> clear max
octave:5> [loopt, mint, maxt] = mmt2(1000)
loopt = 0.0089990
mint = 0.044993
maxt = 0.043993
octave:6> [loopt, mint, maxt] = mmt2(1000)
loopt = 0.0079990
mint = 0.043993
maxt = 6.1731

Clearing can be in any order, but clearing just one won't do.

And maybe this will be more revealing.

octave:1> max(5)
ans = 5
octave:2> [loopt, mint, maxt] = mmt2(1000)
loopt = 0.0079990
mint = 6.1271
maxt = 0.042994

<exit>

octave:1> max(5)
ans = 5
octave:2> clear max
octave:3> [loopt, mint, maxt] = mmt2(1000)
loopt = 0.0089990
mint = 0.043993
maxt = 0.042994

So, it would seem to have something to do with the recording of the time 
stamp for the first variable, yes/no?

I wondered if it could be that there is only one time stamp per file.,  
And the functions that are in the same file are competing for that 
stamp.  Whoever gets to it first is OK, but the second function always 
looks out of date.  That might explain why breaking it into two files 
fixes things.

However, no, that doesn't seem to be the case.  One of those internal 
files has several functions:

getgrent.cc:DEFUN_DLD (getgrent, args, ,
getgrent.cc:DEFUN_DLD (getgrgid, args, ,
getgrent.cc:DEFUN_DLD (getgrnam, args, ,
getgrent.cc:DEFUN_DLD (setgrent, args, ,
getgrent.cc:DEFUN_DLD (endgrent, args, ,
getpwent.cc:DEFUN_DLD (getpwent, args, ,
getpwent.cc:DEFUN_DLD (getpwuid, args, ,
getpwent.cc:DEFUN_DLD (getpwnam, args, ,
getpwent.cc:DEFUN_DLD (setpwent, args, ,
getpwent.cc:DEFUN_DLD (endpwent, args, ,

I picked four of these functions and get:

octave:1> [loopt, t1, t2, t3, t4] = ppt(100)
warning: function name `mmt2' does not agree with function file name 
`/home/sebald/matlab/sergatskov/ppt.m'
loopt = 0.0019990
t1 = 0.011998
t2 = 0.020997
t3 = 0.011998
t4 = 0.019997
octave:2> [loopt, t1, t2, t3, t4] = ppt(100)
loopt = 0.0019990
t1 = 0.010998
t2 = 0.64790
t3 = 0.010998
t4 = 0.64590

The problem appears in pairs perhaps?

Guess that is all I can sniff out.

Dan

  function [looptime,time1,time2,time3,time4]=mmt2(N_loop)
    t = zeros(6,1);
    k=1;
    t(k++) = cputime();
    for i=1:N_loop
      j = i;
    end
    t(k++) = cputime();
    for i=1:N_loop
      j = getgrent();
    end
    t(k++) = cputime();
    for i=1:N_loop
      j = getgrgid(1);
    end
    t(k++) = cputime();
    for i=1:N_loop
      j = getpwent();
    end
    t(k++) = cputime();
    for i=1:N_loop
      j = getpwnam("thisguy");
    end
    t(k++) = cputime();
    x = diff (t);
    looptime = x(1);
    time1 = x(2);
    time2 = x(3);
    time3 = x(4);
    time4 = x(5);
  endfunction