From maintainers-request at octave dot org Wed Feb 9 01:38:04 2005 Subject: Re: min function very slow? From: "John W. Eaton" To: maintainers at octave dot org Date: Wed, 9 Feb 2005 02:43:11 -0500 On 30-Jan-2005, I wrote: | If you have min and max in .oct files, then they are really defined in | the same file (minmax.oct) and the min.oct and max.oct files are just | additional links in the filesystem. It seems that the second one | loaded is much slower. I think this must be some accidental overhead | in checking whether the symbol needs to be reloaded. The problem goes | away for me if I define min and max in separate files (i.e., create | min.cc and max.cc, each with only one DEFUN_DLD macro) or if I set | ignore_function_time_stamp = "all" (I'm not sure why setting it to | "system" fails, even when the min/max functions are installed in a | "system" directory). | | I'll try to check it out more thoroughly. I'm traveling, so it may | be a week or so before I can get to it, so if someone else can pin it | down more completely (point out the code that is wrong), that would | help. I've done some more checking. The problem is that when trying to determine whether a symbol is out of date and should be reloaded from a file, we get the wrong answer for functions that have been found in .oct files that have already been loaded. Here's why: For the first function loaded from a .oct file (say min, from min.oct, which is a link to minmax.oct), we save a pointer to an object that represents the .oct file. That object contains information about the name of the file that was opened to load the .oct file (in this case, /some/directory/min.oct) For the second function loaded from the .oct file (say max, from max.oct, which is a link ot minmax.oct), we also save a pointer to the object that represents the .oct file. This object will contain information about the name of the file that was initially opened to load the .oct file (in this case, /some/directory/min.oct, NOT /some/directory/max.oct) When we check to see if a file is up to date, we look in the filesystem again for it and try to decide whether the name we find is the same file. Currently, the code to do that looks something like this: if (file_name_we_looked_up != file_name_cached_in_function_object) return true; // symbol is out of date and should be reloaded else { if (time stamp of file_name_cached_in_function_object is more recent than time stamp of file_name_we_looked_up) return true; // file has changed since last loaded, so it } Instead of just checking to see whether the names are the same, we should be checking to see if the names refer to the same file. That can be a bit tricky, but it's not impossible. There is code to do it in the coreutils package, but it needs some work to be adapted for Octave. jwe