[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: min function very slow?
From: |
John W. Eaton |
Subject: |
Re: min function very slow? |
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
- Re: min function very slow?,
John W. Eaton <=