|
From: | anonymous |
Subject: | [Octave-bug-tracker] [bug #59706] Avoid "canonicalize_file_name" on Windows |
Date: | Mon, 4 Jan 2021 13:01:41 -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 #32, bug #59706 (project octave): The reason that I didn't use Very Sleepy to get the call stack is that it samples function calls and generates multiple call stacks that aren't precise enough and call stacks for the same function calls are different. So I used API Monitor to capture most important Win32 API calls for just one invocation of 'find_function' . The most important difference that I can see between 5.2.0 and 6.1.1 is when a path folder contains a private sub-folder. In this case Octave tries to canonicalize that path. In other words to find a function 'foo' Octave traverses all folders on the path. For each folder the Win32 API functions like the following is called internally: GetCurrentDirectoryW FindFirstFileW GetFullPathNameW Following that for each folder a private sub folder is assumed and again those API functions are called for those possibly non existent private sub-folders. If such private sub-folders are actually exist 'canonicalize_file_name' is called that is very expensive and depending on the length of a path it invokes near 25 API functions. If function 'foo' is found it is cached to prevent the cost. Again for function 'bar' if it has not been cached the above mentioned process is repeated. I argue that functions such as 'canonicalize_file_name' and even 'make_absolute_filename' should only be called on user provided paths. Other [system provided] paths by default should be full and normalized. I believe the patch related to bug #59711 is great specially that it removes 'canonicalize_file_name' calls for private folders. Thanks! Unfortunately I don't set up the build and possibly we should wait for 7.1.0. I attached the API calls mentioned in comment #30 as separate two text files. _______________________________________________________ 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] |