John W. Eaton wrote
> On 2/2/20 1:18 PM, PhilipNienhuis wrote:
>> While running __run_test_suite__ with a freshly cross-built Octave-6.0.0
>> on
>> Windows, I saw a FAIL in run.m.
>> That FAIL has been there for quite some time, didn't bother, "test run.m"
>> works fine when run outside of __run_test_suite__.
>>
>> But because since one or two days Octave on Windows suddenly takes a very
>> long time to load I added some tic/toc statements in
>> chk_spreadsheet_support.m, invoked by __init_io__.m, in turn invoked by
>> PKG_ADD in the io package, to find out if loading Java classes for
>> LibreOffice would take so long. I saw no strange things there, finding &
>> loading loading the .jars takes altogether ~5-6 seconds of in total 25
>> seconds for he gUI to appear until the prompt is shown.
>
> Can you bisect and determine which changeset caused the difference in
> behavior?
>
> If it is something that happened recently, maybe it is an unintended
> side effect of this change:
>
> http://hg.savannah.gnu.org/hgweb/octave/rev/262cdfc6faf9
>
> which made the load_path class use the absolute canonical directory name
> as the key for the private function map?
(sorry for coming back to this thread a bit late.)
Right, it is exactly that cset that makes the difference.
What else can I do to investigate? Would it help to open a bug report?
Looking at still open bug #57439 tied to that cset [1], best might be to add a comment over there with an impact summary.