|
From: | anonymous |
Subject: | [Octave-bug-tracker] [bug #59706] Avoid "canonicalize_file_name" on Windows |
Date: | Fri, 15 Jan 2021 04:51:45 -0500 (EST) |
User-agent: | Mozilla/5.0 (Windows NT 5.1; rv:68.9) Gecko/20100101 Goanna/4.6 Firefox/68.9 Mypal/28.14.2 |
Follow-up Comment #42, bug #59706 (project octave): According to the result of APi Monitor the only occurrence of canonicalize_file_name is when a path folder contains a 'private' sub-folder. I assume that all path folders are already canonicalized. They can be canonicalized on Octave startup or when a user use 'cd' or when they use 'addpath'. A private path is just path + sep + "private". Does this private path need to be canonicalized again and agian? NO. In bug #59711 comment #13 a patch is submitted that eliminates canonicalize_file_name calls related to private folders. If I correctly understand it uses uid instead of canonicalized name in private_fcn_map that possibly increases the performance of Octave 7 relative to Octave 5.2.0. But a fix for the stable branch is just not using canonicalize_file_name because the path is already canonicalized. My suggested patch for Octave 6 to preserve the speed of Octave 5.2.0: -private_fcn_map[sys::canonicalize_file_name (full_dir_name)] = private_file_map; +private_fcn_map[full_dir_name] = private_file_map; ... -private_fcn_map.find (sys::canonicalize_file_name (dir)); +private_fcn_map.find (dir); Please correct me If I'm in a wrong way. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?59706> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
[Prev in Thread] | Current Thread | [Next in Thread] |