From maintainers-request at octave dot org Sun Jan 30 03:26:20 2005 Subject: Re: min function very slow? From: Daniel J Sebald To: maintainers at octave dot org Date: Sun, 30 Jan 2005 03:32:37 -0600 This is a multi-part message in MIME format. --------------010605020907050705010705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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 --------------010605020907050705010705 Content-Type: text/x-objcsrc; name="ppt.m" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ppt.m" 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 --------------010605020907050705010705--