[Top][All Lists]

[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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]