octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #59706] Avoid "canonicalize_file_name" on Wind


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #59706] Avoid "canonicalize_file_name" on Windows
Date: Thu, 14 Jan 2021 08:09:58 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36 Edg/87.0.664.75

Update of bug #59706 (project octave):

                  Status:          Ready For Test => In Progress            

    _______________________________________________________

Follow-up Comment #40:

Re comment #38: Thank you for that information.

IIUC, most of the time seems to be spent in
ZN6octave3sys22canonicalize_file_nameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE.
That is most likely `std::string canonicalize_file_name (const std::string&
name)`:
https://hg.savannah.gnu.org/hgweb/octave/file/b73ddb964093/liboctave/system/file-ops.cc#l693

The compiler seems to have inlined a lot of functions because the immediate
parent in all stacks appears to be
ZNK6octave9load_path3addERKNS0_8dir_infoEbRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb.
That is most likely `void load_path::add (const dir_info& di, bool at_end,
const std::string& pname, bool updating) const`:
https://hg.savannah.gnu.org/hgweb/octave/file/b73ddb964093/libinterp/corefcn/load-path.cc#l1225

But the function that calls `canonicalize_file_name` is probably
`maybe_canonicalize` in the same file:
https://hg.savannah.gnu.org/hgweb/octave/file/b73ddb964093/libinterp/corefcn/load-path.cc#l58

I added that function to resolve bug #56267:
https://hg.savannah.gnu.org/hgweb/octave/rev/51d26dd80828

IIRC, that bug boils down again to the fact that we use the canonical path as
a unique identifier. We can't use the (not canonicalized) path directly
because different strings might identify the same path in the file system.
Much more so on Windows with its long and short file names, different
directory separators ('/' and '\'), and case-insensitive file system.

There are two strategies I currently see to improve the performance here:
* Check if we really need to call `load_path::add` so often (100s of times if
I read the data in the Very Sleepy profile correctly).
* Check if it is possible to use something else than the canonical path as the
unique identifier when managing the load-path.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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