[Octave-bug-tracker] [bug #59706] Add function that normalizes a file path

[Rik]

Follow-up Comment #7, bug #59706 (project octave):

@Markus: Since there is already a function to normalize a file path, and it is
fast, can we re-title and re-position this report to be about performance?

canonicalize_file_name should be fast because it is a library call.  On some
platforms, where the implementation is broken, we use gnulib to swap in our
own compiled version of the function.  That might be the case with the
reporter's computer.  I can't really tell because the Operating System is
marked as "Any".

I can see several things to do that might result in a solution.

1) Look at whether canonicalize_file_name is slow on a particular platform,
such as Windows, and substitute something faster for that particular OS

2) Substitute our own version which is make_absolute_filename() combined with
a try/catch block around and existence test for the object.  Benchmark it and
see if this is faster.

If the problem is really just that the function is slow then the way out seems
to be to call it fewer times.  That's simple to state, but the devil is in the
details.

canonicalize_file_name does two things: 1) it expands a relative or path
fragment to a fully qualified path, and 2) checks for the existence of the
named object (file or directory).

Unfortunately, it would require looking at each instance where we call the
function to see whether we are making use of one or both features.  I do know
that a fair number of the instances we are using the function to test for the
existence of a file so substituting make_absolute_filename() will not work.

That leaves re-architecting to reduce the number of function calls.  I can
think of a few opportunities

A) Octave needs to check whether functions have been modified before calling
them.  However, it only needs to do this each time it returns to the prompt. 
We should make sure that Octave, while executing a script, isn't trying to
check for updates after every line is executed.

B) The load_path is cached and the function location and other ancillary
information is also cached.  Is this system somehow not working and a lookup
in the symbol table is causing an overly frequent search of the disk rather
than just a search in memory of the cache?

C) Perhaps a small thing, but the caching is done with C++ standard maps which
are O(log2(N)) in performance.  Now that Octave supports C++11 we could move
to a hash-based map from the standard library and get O(1) lookup
performance.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59706>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/